Craig Brown
Evaluator
Posts
Story Mapping is an Agile technique for managing product backlogs developed by Jeff Patton. I first discovered the term Story Mapping via a blog post by Jeff called The New User Story Backlog is a Map. The blog post is a very insightful and clear explanation of Jeff's motivation for the idea. Rather than me repeat his content in detail you should just go read his content.
Jeff himself first articulated the idea publicly in an article in Better Software called How you Slice It (free PDF.) It's a technique for sorting and simplifying backlogs that are too large and complex for a simple list. How can we create different views on the backlog that help us understand what is happening and how the product is evolving?
There are arguments against the story map concept. The one that springs to mind is that you should have a lean and small backlog and so you shouldn't need all this high faluting modelling. In reality, most of us, especially those of us in large organisations, need tools like this to help us sort through the complexity.
When I talk about Story Maps in training and coaching sessions I am always drawn to BJ Clarke's diragram which I think is great. What I like about this diagram is the way he blends the structured three tier form of a story map with the rough and ready hand drawn notations. For me this just feels like a good diagram. Thanks BJ.
Another blog post I discovered via the nice diagram is via Dreamfeed, which also has a really nice blog post on Story Mapping that I think you should read.
Story maps don't stand alone in Jeff's metal model for managing product development. This all happens in a context that includes developing persona's and designing with the user experience in the centre of your thinking processes. It's all about thinking big picture so you can delight your clients. A micro-focus is good when doing the work, but a macro-focus is also needed when thinking about the customer.
For example, when I create story maps they end up looking very much like a top three layer of a WBS with a Prince2-like product breakdown style to them. They don't always end up like this and they don't have to either. Other people I know fall into other habits like building story maps around process maps. I am not sure what Jeff thinks off these variations on his idea, but I'll keep an eye out on the topic.
What stories do you have to share about Story Maps?
A topic I still haven't reconciled in my study of management theory is whether systems are 95% of the success or failure of a process (Deming) or whether it's People over Process (Agile Manifesto.)
Of course it's neither, and that both systems and people matter, but I haven't squared away the dichotomy into an easily managed aphorism yet.
Perhaps "systems that enable people" are they key. Or perhaps it's "systems that facilitate collaboration."
There is no doubting that systems play an important part in getting things done. But in what ways to systems and people interaction find the optimal balance. And what is the model illustrating the point?
Karl Scotland has done a nice blog series on the science underpinning the Kanban Method (with a little help from Clark Ching's multi tasking game.) I highly recommend reading the following posts:
I signed up as a line manager of a team of business analysts and web developers at a large corporation. My role was to manage the team which had three main functions; (1) identify and implement process improvements into call centres an back office processing centres, (2) co-ordinate communications and training around new product roll-outs, and (3) act as SMEs and process analysts for infrastructure and new product development projects.
The team were, when I joined them a classic case of the “No department.” Business analysts and project managers that had to work with them did so only under sufferance. Frontline business unit managers groaned as the technocrats rolled out a new procedure in an increasing complex and difficult environment. Quality assurance officers and frontline workers, often in dispute over what constituted the right way to do work, cheered them as they ironed out all grey areas in all procedures and work instructions.
I realigned the team structure to mirror the client organisation’s structure and changed the role from one oriented to product and process orientation to one of client focused consulting. The team’s new brief was to spend time in the call centres and processing arras and look at operations from their client’s point of view.
Opportunities for improvement were to be assessed on the size of the problem and the potential for improvement- a minor business case analysis. Candidates for process or system improvement were identified from first hand interaction with users and customers, and from data from operations report. They were then prioritised based on evidence. Solutions were implemented in partnership with the operations managers and their teams.
The consultants’ new role was to help local managers discover the most important pain points and help facilitate the solutions, not to impose tinkering on work instructions and create impediments to capitalised projects. Within 12 months stakeholder satisfaction feedback had increased five-fold, clear and measureable benefits worth several millions of dollars had been rolled out and most of the tinkering had ceased.
My role as manager, after changing the system the team operated in, was to coach the team members in consulting, analysis and problem solving skills, but essentially they created their own virtuous improvement cycles by talking among the team and dealing directly with their own set of clients.
Introduction
A User Story is a marker indicating a request for work to be done.
User Stories are often conflated with software or business requirementsbecasue on first impressions they look like requirements. They are actually independent things.
User Stories were first introduced to the world by the XP community in the late 1990s, although the concept of stories and narratives being effective tools for communicating requirements daes back at least into the early 1980s.
Important things to consider about User Stories
- They are a token for doing a piece of work and are not a software requirement in the traditional sense
- They are a 'trigger for a conversation ' and build upon the Agile Manifesto principle that face to face conversations are the most effective form of communicating ideas
- A User Story is likely to evolve over time as people's knowledge on the topics area matures
- Generally, when a software team starts work on a User Story a clear 'definition of done ' should be available
- User Stories are ideally written on index cards or similar because of the value of visualizing the workflow , keeping them simple and osmotic communication .
The three essential elements of a User Story are the card, conversation and confirmation.
These are described below under the following headings.
- Card = Physical v Electronic
- Conversation = As a Product Owner I want a template
- Confirmation = Start with the end in mind
User Stories are typically written on index cards or post it notes because of the value of osmotic communications, the lightweight nature of the tool and because face to face communication is optimal for project team communications.
Many teams also capture User Stories in electronic media such as requirements management or test tools.
There are many purpose build product backlog management tools on the market.
As a product owner I want a template so that it's easy
Since the mid 2000's a 'common form' of User Story has become dominant. It is presented in the following form;
- As a [user type]
- I want [an interaction+outcome]
- So that [I get some form of value]
The "I want" element generally describes some tangible interaction or feature. Because of this element a User Story is often conflated with a Use Case, a scenario or a feature. And it may well describe any of these or other thing.
Again partitioning is relevant and important here. But the main driver in this space is to partition the work into a small, independent pieces of work. (See the INVEST mnemonic.)
Software developers usually have a lot to offer in relation to requirements and how they should best be fulfilled. Often they have been constrained by a lack of awareness of the motivation for the requirement. It's also a common client failing to jump to solutions to early. Asking for the motivation in terms of business value helps everyone focus on what's most important in the story. SO explain why in the "So that" clause.
But the template has it's detractors.
By proving a tamplate in the first place you provide a platform for people to communicate in written form with the idea that the communication is sufficient and complete.
Unlike requirements a User Story is not a complete brief. It is aimed at being a trigger for a conversation and is purposefully incomplete so that the conversations can be had to further elaborate understanding collaboratively.
Start with the end in mind
A clear definition of done is important for User Stories as they re work requests. By being clear about 'done' teams are better able to determine when they have not yet met the minimum quality and capability thresholds, and when they have gone too far.
Typically the definition of done is created via a test case or acceptance criteria prior to commencing work on the user story. Early User Story advoctes simply used the trigger "This will be done when..." to stimulate the discussion on 'done. More recently the idea has been elaborated.From the same vector as the "As A, I want, So that" template comes Behaviour Driven Development (BDD.)
BDD is more than just a form for acceptance criteria. It is also a framework for managing stories and requirements more broadly. But it has also been adopted as teh dominant form for acceptance criteria on User Stories with the template;
- Given
- When
- Then
Further reading
- Mike Cohn's User Stories Explained
- Wikipedia on User Stories
- c2.com on User Stories
- ExtremeProgramming.org on User Stories
- Scott Ambler on User Stories
- User Story Template
- INVEST - A quality checklist for User Stories
- Kanban - another concept for work tokens
- Story Maps - a way of managing large numbers of stories
- Behaviour Driven Development - Test thinking applied to stories
- Stories as Inventory - understanding the cost of too many stories (or requirements)
In the early days of this blog I was exploring and discovering techniques and models from the engineering paradigm of project management and requirements. I learned a great deal of useful stuff, some of which is re-emerging now as part of the Kanban movement. Given there is so much interest out there in the agile thing I thought I might try a regularly and specifically themed agile blog.
I'll be drawing the post topics from the local Agile meetup groups. Their goal will not be to give definitive answers on topics, but to raise awareness and to provide a platform for further investigations. I hope they are useful.
If you want to see a summary of all the topics covered to date try searching the blog for "Agile Thursdays."
And they can become mindless activities as well. Checking the box unthinkingly, or adding new items to the checklist without ever taking the time to trim some unnecessary items.
But I reckon they are still better than templates. They are definitely more lightweight.
I just created a checklist to help someone with little project experience think through their project needs. Take a look. I'd appreciate some feedback.
This sat in draft for a while. It's about bureaucracy, PMOs and change.
Some quick questions to get you involved;
- Do you know the people in your PMO?
- Do they know you?
- Are they committed to seeing your project succeed?
- Really?
- Or are they just about process compliance and weekly status reports?
(PMOs are a nebulous thing, so I might run up another post on my views on what makes a good PMO at another time.)
I recall once I had to go into a meeting where I had to justify why I wanted to create addional project documents, and why I wanted to vary from the usual tempaltes.
The reason I wanted to do 'extra' documentation is becasue we want to demonstrate new processes and methods for the organisation, and as a result want to keep them comfortable while w experiment with their people and processes.
We'll follow good agile practices and do fortnightly product reviews, and product burn up charts, and we'll also provide a report showing time and money spent against a target. We'll work with a backlog full of user stories, and we'll also provide a high level requirements summary for our main release phases, one at a time, focused on the next release.
We definitely want to present a Project Management Plan, and a Quality Plan and Communications & (people) Change Management Plan which aim at explaining our methods and thinking through some of the more complicated parts of the program.
So, if I want to go above and beyond in terms of project documentation why the hassle?
Well, for one thing I also want to omit redundant documentation. In particular some of the requirements documentation. We already have plenty of detail to hand, so why both rolling it up into multiple summaries and decompositions? We already have a product vision statement and release roadmap so why elaborate that into additional documents that are at the heart of many project failure modes.
And while I am on the topic of reducing overhead, I would really like to abandon the template approach to documentation. I get the point of templates, and in the past templates have helped me learn, but checklists are a much more effective tool than templates and make for less overhead
I specifically want to abandon the parts of templates that repeat the same shot over and over again so the repetitive and incidental details can be cleared out of the way, and so that important information can be added. Remember white space? I want a crisper and clearer message. I want the readers to engage with the content.
When I was an undergraduate at university studying marketing we were discussing the Marketing Mix. "When launching or developing a product..." the lecturer said, "pay attention to Price, Promotion, Product and Place..."
I sat there thinking. I didn't have corporate experience and this didn't make sense. It just seemed to simple and to pat. (Four Ps!) I was trying to learn this stuff by applying it to the bar and restaurant jobs I had.
How can I apply the four Ps to the restaurant? We can't move it, especially me as a waiter, so the distribution aspect is a moot point. Maybe we can change the prices and the menu (product) and sure we could do something to raise the bar when it came to promotion. But what about the other aspects - the relationships the staff had with each other, the way we interacted with the customers, the suppliers (especially the alcohol sales reps!)
So I said as much to my lecturer; "This doesn't seem to be enough. Surely you need to think through more than this to launch and manage products."
It was then I got one of the best nuggets of information from that degree.
"It's just a checklist to help you along. It doesn't give you all the answers. You have to use your brain to solve complex problems."
I wonder how he remembers the conversation, if at all.
He said I was the only person he knew who loved their job.
The sad part is, I don't think he's far from wrong. I do work with several people who I know do love their jobs and it is clear from my daily interaction with them that their passion for what they do comes through in every conversation, every email and every line of code.
Its people like this, those who think of what they do as craft, who inspire me. I'm lucky; in my current job, I'm fortunate to have many of them who work with me. In my career, I've worked with people who are all over the spectrum when it comes to intelligence, motivation, perception, knowledge, wisdom and taste, but rare has been the person who really has a passion for what they do.
Passion is fleeting, but when it is really intense, its something that has you and not the other way around. Its something that I don't think you can fake; its either present in what you're doing or its not. The quality and the responsiveness of your work is directly correlated to exactly how passionate you are about it.
Even though I crossed the line years ago from individual contributor to manager, I still make it a point to regularly go back and do some business analysis work just to keep my skills sharp. Strangely enough, every time I sit down to do a bit of light analysis on a project, I can't help but remembering why I love this kind of work so much, why it fits me so much. Simply put, I get to make a difference for someone (or as I am fortunate enough to do, for millions of someones).
Given that passion, it probably shouldn't be a surprise to any of you that I obsess about projects. There isn't a better way to illustrate this than to realize that for two years (minus the last 4 months), I've been regularly writing on this blog. That isn't easy, especially with a crazy workload, long commute, a 2 year old and a small bit of socializing. Obsession over this topic is something that drives me, not the other way around.
Obsession is a powerful thing that John Gruber and Merlin Mann nailed. Listen to the audio in the link on this page as these are two guys who really understand what it means to take obsession and give it voice. Their obsessions are different, albeit related, to mine and I strive to have a voice that is as strong as theirs. In particular, pay attention to Merlin's discussion of writing about Jawas. Brilliance.
One of the things writing on this blog has helped me with is to find my voice. The last couple years have helped me refine what I really feel is important in a project and the direction I think projects will take in the coming decades. Technology, especially in the mobile space, stands to make a radical shift in how we elicit, document and analyze requirements.
The biggest change, in my mind, will be using video in the requirements process, especially agile processes. We can already do this today, but mostly its done by making some kind of prototype or slide deck, narrating over top of it and letting your remote users get a feel for what it will be like to use some kind of application. Pulling all that together into a produced video takes lots of time and planning. I don't think this will be how we do it in 20 years.
I see our business users watching someone failing at a process, pulling out their pocket communication devices (we better not be calling them phones then!), snagging a video of the incident, tagging spots in the frame, adding some text or commentary on top of the video, emailing it to the project team and waiting a few hours (better yet, minutes!) for the adjustment to the system to be made.
Or how about the stakeholder using that pocket communication device to make the adjustment themselves! Instead of creating only the tool used by the person performing the process, why not create the next great app that is used to create the next next great app?!?
Its ideas like this that really get me excited. My obsession is going full speed and my voice is coming along. I hope you all can say the same.
I have been over editing Wikipedia again. This time on Functional Requirements.
Yes, it's the poor quality that revolves around the Requirements and analysis topic that drew me in. Wikipedia's content in this space is a classic example of the plumber with leaky pipes syndrome. Each time I see it I just can't help myself. I have to edit.
But this time I am stuck.
My question for you dear reader is this;
Where does the idea of the Functional Requirement (as opposed to just a plain ol regular requirement) come from? What is the origin story of this mystical term?
And while I am here, can you share your view on what the essential elements are that make a requirement "functional?"
Thanks in advance,
Craig
Next month we are going to have a lunchtime session at work on stakeholder analysis so I did a little research on the topic and came up with a list of useful ideas. They are posted below with some links.
I am thinking about:
- What does stakeholder mean?
- What boundary conditions help define who is and isn't a stakeholder
- Why analyse stakeholders?
- Techniques for identifying stakeholders?
- Techniques for analysing stakeholders?
- The power/influence matrix
- Mapping stakeholder via KRAs
- Ranking stakeholder needs
- Networks of influence among stakeholders
- Integrating different analysis models
- The stakeholder circle model (more examples) from Mosaic
James led a project team that was to investigate and address improvement opportunities for the online sales channel for a financial services organisation. The sales process was mapped and charts put up on the wall of the call centre, where most of the back office work was done.
Subject matter experts from the call centre were asked to inspect and comment on the chart, and to nominate suggestions and improvements. The analysts stood back and made o recommendation. Their contribution to the conversation was to elaborate and explain the diagrams and their notations, and to make corrections as frontline staff observed variations between the model and reality.
The operators identified several bottlenecks and activities that yielded little more than customer or staff frustration. The analysts captured the issues and documented them, later reporting them back via updated models.
By the time the documents had arrived two weeks later the frontline team had already taken action to streamline their process and optimise it for customer experience. Sales had already risen and without any further action the project could well have been called a success.
Bureaucracy is a form of organisational structure. It is not the paperwork and busywork we see in large organisations. That is something different. It is waste, inefficiency and an inside out view of dealing with customers.
But they seem to go together, don't they?
In the next few weeks I want to go through some of the ideas about what a bureaucracy really is, where it came from, what it's strengths and weaknesses are, and what we should do with it when considering the design and creation of new workplace systems and structures.
And why is it they are so frustrating to deal with?
Here is a tentative roadmap for the discussion. I'll update it with links as I write the posts.
- What is Bureaucracy
- Origins of Bureaucracy
- The Evolution of Bureaucracy
- Organisational theory on Bureaucracy
- Alternative Models for Bureaucratic Organisations
- The future of Bureaucracy
On an application development project I had problems with estimating the details of software projects and managing feature creep. We were tracking okay to the high level estimates we had put together pre project, but on a story by story there was very little accuracy in estimates.
As we know from Kailash's blog post delphi planning (e.g. planning poker) amplifies estimating capability. If your skills are good, the group approach makes it better. But if your skills are poor you'll just amplify your error rate. We seemed to be stuck in the second category.
Watching the cumulative flow and cycle times on stories gave me the right cues to take information to the plan with a recommendation. I could see the average story size was also the threshold for estimates breaking down. So, on average the effort to fulfil a story was going to vary substantially form the estimate. The threshold was a story of about 5-6 days of effort.
I put it to the teams that we target a 2 day maximum effort story size as a threshold, and if stories were larger we break them down further until they fit into that threshold. This was generally accepted (but not consistently applied.) The additional effort in breaking down stories increased flow and yielded improved results (which still needed further improvement.)
My role was in the analysis of the team’s performance data and linking the problem of large stories with size limits. The team were able to adopt this change and the positive results were shown in future performance reports.
This led to me generally advocating the “count the stories” mantra alongside the Kanban method community. I’ve also combined it with the Requirements Traceability technique to good effect. (see more here.)
Kailash wrote a great blog post on estimating. It gives the maths behind why you guys suck at estimating.
Go read the post here.
Kailash tells us that essentially your success at estimating is amplified by doing it Delphi (blind group) style. This includes Mike Cohn's planning poker approach to estimating.
That means that your estimates increase your capability if you get many people involved. Unfortunately, if your team's average estimating capability is poor you'll be amplifying poor estimates (ie moving further away from the eventual truth.)
His post comes with disclaimers and it would be neat to test this out with some experiments, but it is one of those ideas that 'feels' right.
This post is my response to the ideas he presents and some additional thoughts on the problem of estimating.
It's timely for me right now because I have been doing some estimating work for my team's 2012 portfolio and I have been pretty much ignoring all recommended best practices for estimating and instead guessing most initiative sizes using my instinct.
What makes me think I should be doing this rather than using a consultative, and in particular a Delphi approach to estimating projects?
Why am I more reliable than many other people who have worked here longer?
First and foremost I believe that most in our team are not particularly competent at estimating. So I trust my judgement more than theirs. I've been around and educated myself about estimating. I have also been around and gotten a feel for how much effort things both 'should' and 'do' take in organisations of various maturity. I have a breadth of experience.
Additionally, in my current estimating work I looked back at historical performance and looked at sizing next year's projects against last years. This gives me a feel for the capability of the organisation. Relative sizing works for me.
Additionally I don't actually do it alone. I have asked others to estimate in some instances. But again I have gone to individuals rather than the whole team that is to do the work. (Some teams aren't even hired yet.)
So Kailash's post gives me confidence hat I am not doing something stupid and there is some theory that stands behind my instinct to keep the estimating activity to a small group of people.
There is a better way.
You may suspect that better way could be developed by giving everyone experience participating in estimates so they can build their competence. We could do that, and should for a handful of people for the occasions we do need to estimate things.
The better option is to gather historical data and use that to forecast the future.
In the course of next year I'll be working the team to gather data so we can get better historical numbers. In the next annual planning cycle I hope we'll be 'counting cards.'
Dave Gray talks on using games to help design products and work. A key point I liked was that by involving users and clients in the creation of products (and knowledge artefacts like user stories and requirements) you get them championing your project efforts in a much more engaged way.Enjoy.
I was recently in a competition which involved doing a 60 second elevator pitch to a panel of judges, and learnt more than I expected from the experience.
My first main takeaway was the amount of effort required to really crystallise into just a few words the problems which I was proposing to solve. Expressing the problem is the absolute kicker in a product pitch, but it also made me reflect on my BA work. The standard requirements template I work with every day has a 'business need' section under the title. It can be easy to get lazy with that and just basically restate the requirement title in more words, rather than go that step further to actually capture the essence of the problem.
Likewise within the standard user story format, what follows the '...so that' component should really hit home to help everyone understand the value of what we are setting out to achieve. A nice metaphor that was passed on during one of the competition pitching workshops was "put your listener/reader 'out in the hot desert' with your problem description, so by the time you propose your solution they are so thirsty they're willing to pay $1000 for the glass of water you are offering!".
The second takeaway stemmed from standing in front of actual investors and feeling the potency of the situation - I'm asking these people for cold hard cash and they need to be convinced of the financial return they'll receive on the basis of this idea/solution!
This experience has given me a new perspective. Sure, my project stakeholders aren't usually dipping into their personal finances, nor are the risks as high as funding a startup idea. But still, there are stakeholder's professional reputations and real money on the line. As a BA I need to play my part in making sure that the problem actually exists, it has been properly analysed and captured, and that measurable value is delivered at the end of the day.
If you're passionate about what you do, this likely frustrates you. What you really want, more so than anything else, is to exceed their expectations, delivering them the most perfect solution in the world. When you are unable to do that, you probably feel some resentment, not toward your stakeholder or yourself but to whoever imposed that constraint on you.
But it occurred to me during my drive home today that maybe we've all got the wrong image of constraints in our heads. Maybe, instead of bemoaning the limitations that constraints put on us, maybe we should learn to embrace constraints as a good thing. Don't believe me? Lets think about a couple types of constraints and see if a shift in viewpoint could change the way we approach a situation.
Lets say that one of your company's rivals just released a spectacular new product that has instantly made your company's products look obsolete. The finance team has done a few calculations to show that revenue projections will slip by 25% by the time your next new product is released that will return the market to its previous parity. Your product development team has started on a project to create that new product, but is months if not more than a year away from completion.
At this point, you've got a problem. Marketing suggests changing the target market. The sales guys are in favor of slashing prices and moving more units. The production group screams in protest; that they can't keep up with orders now, much less at larger volumes.
You're asked to figure out what could be done to keep the company going until the next big product is done.
First, you recognize a time constraint. The project team needs a year to get a totally new product out to market; one that will, you hope blow away your competition... but your company doesn't have a year to wait. The right question to ask in response to this type of constraint is what can be accomplished quickly that can, if not return the market to parity, to at least get your product to be more competitive.
Its time to start looking for easy options: change the product's color, add in cheap bundles to increase the value of the product, look for opportunities to co-market the device with related products. In short, its time to start thinking of what you can do within a reasonable period of time and not what you can't do with all the time in the world.
Next, you recognize a cost constraint. If finance is projecting such a dire sales slump and your company doesn't have the free cash to keep running at the current cost structure until your new product can turn sales around, its likely you won't have the staff or budget to finish that project in the projected year. If your company cuts staff, the project will take longer. If the budget gets cut, your quality is likely going to suffer.
One way to combat a cost constraint is to figure out ways to mitigate the loss in sales. One way to do this is to offer incremental improvements in your current product that can be delivered in a very short time frame. Change that analog display to a digital one. Reconfigure your site layout to remove confusing features so the user can focus on what is really important to them. Put together a list of the things consumers most dislike or would most wish to see included in your product, prioritize them into a list and determine a strategy to make those things happen.
Last, what about a resource constraint? What if your company's huge project is pulling in all resources while other products of lesser importance fall by the wayside. What do you do when what you are responsible for is having all its resources pulled into a big resource black hole?
You can look for other resources, but you're not likely to find them as the company has already realized its not going to have the money for the big project, much less your small one. You know you've got customers using your small product daily, but they're not getting the support your sales team promised them.
It can be painful, but sometimes your best option is to simply embrace the constraint. Maybe the more time you give to the big project, the faster it reaches completion and the sooner it is your resources come back to working on your project. There are times when all you can do is give in to the constraint.
So what constraints are you dealing with in your organization? How are you dealing with them? Let us know down in the comments!
Folks I am running my online Intro to User Stories course again. Sign up via the training page on this site.
Once again the course is free. I have taken on feedback from the last group and spread the content out over 5 weeks rather than force people through heaps of stuff in 5 days. I hope it's a little more of a relaxed pace.
If you are interested in what I consider a really good explanation of the techniques and a discussion about the principles and surrounding issues (e.g. "What sort of documentation do we create?) you might like to sign on.
And of course, you should probably refer a colleague.
I love deadlines. I like the whooshing sound they make as they fly by.Back about 3 months ago, I went into a meeting with my department's VP, expecting to walk out with 1/3 fewer team members and 1/3 less responsibility. I was overloaded as it was and had been told my job needed additional focus on a single, strategic project. What really happened was I walked out with 33% more team members, 50% more responsibility and an entirely new reporting structure. Needless to say, I was a bit surprised, but pleasantly so.
This role has been a lot of fun and includes a lot of additional challenges, all of which are in the direction I want to be taking. Its kind of funny that the things in my job I least enjoy (although I do enjoy all parts of my job, its just that I enjoy some parts more than others) are the ones that are most related to my old role. Nothing bad there at all; I just really enjoy the new stuff I'm getting to do.
But along with all those additional challenges come the realization that I can't do it all; that I can't be everywhere at once. Not that I could before, but the realization is just more obvious now than before. I'll be the first to admit that I'm stressed out, often frazzled and in major need of additional sleep. My mind is racing all the time and my focus is fractured more than a glass vase dropped from the Eiffel Tower.
Which is why this blog post, about the effects of being 'busy' rang so true to me. There were a few lessons that popped out at me from reading this:
First, if you're going to be the best at what you do, be prepared for a LOT of repetitive work. That doesn't necessarily mean filling out forms or shuffling paper, it means spending the majority of your productive time being productive, not just going through the motions. This is hard; it requires drive, determination and all kinds of overused and poorly understood buzz words.
Second, you've got to focus on that work. This is the part of the article where I realized that my analysis skills were atrophying from lack of use. I've spent the last few months in meetings 75%+ of my days. That's not necessarily a bad thing, but it does mean I have less time to spend in focused practice on my actual role.
Yes, much of what is accomplished in those meetings is also part of my new role. One of the things that I enjoy about my organization, especially compared to some really dysfunctional former employers, is that we actually seem to accomplish things in meetings. Wasting every hour of the day in useless meetings really stinks, so I know I'm fortunate to not spend the majority of my time that way now.
Which is where I come to the next lesson of this article: attitude. There have been times, especially during those meetings I feel are rolling around in circles, where nothing really gets accomplished, that I just want to storm out and 'go get some real work done'. This rolls over into my non-work life as well. My evenings have been filled up with processing email that wasn't even looked at during the week. I'm a firm adherent to the Inbox Zero philosophy, so a box with dozens of unread emails makes me twitch like crazy. Its something I just can't help but comb through, no matter how much I would rather be reading a good book (or writing on this blog).
And this brings me to the last point, one not brought up by the authors of the study, namely that being great requires sacrifice. If the 'average' players in the study practiced their instrument 2 hours per day and the 'elite' players spent 6 hours in study, that's 4 hours the 'elites' could have spent elsewhere, but chose not to do so. Being great, or at least doing great work, means not doing non-great things.
I think it is this last point that is what is the hardest thing for me personally about my job. I am thankful that I get to spend my time doing a lot of good things; I just wish I got to spend more of my time doing great things.
So that, in a very wordy nutshell, is exactly why I haven't been spending time on this blog in a couple months. I've missed you all, Better Projects readers. I've missed discussing topics near and dear to the hearts of those of us who do projects. In short, I missed trying to work out how to be great with you all. Lets not be apart so long ever again. I won't promise not to stray for short times, but I do promise to always return.
I bring this up because I went to the Wikipedia Business Analysts article again today resolved to have a go at making it better. I usually fail in my attempts because there are so many issues with the page as it is today. Anyway, rather than bite off too much I took a look at BA certifications and well, one thing led to another and I have drafted an article in ISEB to replace the previous poorly formed entry.
My proposed (and lean) article is below. If you have an opinion, I'd like to see your comment below, but even better - head over to Wikipedia yourself and help improve the page.
What is ISEB
ISEB is a part of the British Computer Society (BCS). It is a certification body that accredits people to BCS standards within a range of business and information technology specialisations. ISEB is a acronym for Information Systems Examination Board.
History
ISEB started shortly after the creation of the BCS in 1957 to act as a certification body. The purpose of the certification body was to provide a standards group within the industry in the UK.
Framework
ISEB provides a three tiered certification model from Foundation, through Practitioner level and on to Advanced level.
Subject areas
Certifications are mainly built around Information technology competencies, however within the framework there are also several more generalist management certifications.
Licensing
ISEB licences the ability to delivery courses that prepare for certification.
Other services
ISEB also publishes books, papers and holds events and conferences.
International Presence
ISEB is based in the United Kingdom but claims a presence in over 200 countries, mainly through certified people and training organisations.
Related topics
- BCS,
- Certification,
- Information Systems
Sources for my history notes
In 2009 I first heard this story. It's still a great introduction to how complex problems don't always need complex solutions.
I'm also looking forward to hearing David speak on Wednesday night this week when he comes to Melbourne, and of course to persuading him to come for a beer afterwards.
Updates
-
@mcbridesride apparently everything looks like a nail to autocorrect
-
@mcbridesride I expect you are right. Unless its like an apprentice type thing for newbie hammers :)
-
@james_christie thx
-
Does anyone know how to explain linkless spam comments in blogs? What's the win?
-
@alphajuliet really?
-
@rowanb @josephpelrine @cgosimon @kjscotland @snowded looking fwd to a #calmalpha gig in Australia... Likelihood for this year?
-
@wouterla oh yeah, burn up chart for sure. In this talk I was ignoring the cumulative work done and focusing on the scope variation/time.
-
@wouterla and re BA == PO. It's situational, but it's a direction I like to see analysts move in their thinking.
-
@wouterla burn up also < cfd. Cfd more granular in detail + lead times & bottlenecks
-
@wouterla yes. Many paths to similar outcomes
-
RT @Kurt_Haeusler heh "The police I spoke to said they would rather have 1000 drunk NZers on the street than 100 drunken English" < hobbits?
-
Takeaway from talking to Highsmith: what's more important - theory or outcomes?
-
@wouterla not in front of it right now. Can you tell me where/what context?
-
@wouterla cool. Glad to be useful.
-
My takeaway from the #twlive thing yesterday; the degree to which people use customer segmentation to manage feature switches.
-
@mschedlb re sql/ situational. Is the analyst there to analyse data as part of the role? To design data models?
-
@mschedlb in what way does reqmnts sign off mitigate risk? What risk does it target & what is the likelihood-impact profile where you work?
Posts
We ran a lunchtime session talking about values and how they underpin the way we work. The session closed out with a whiteboard exercise which is described on the last page of this deck. If you use this I’d appreciate your sharing your experiences and feedback via the comments or by email. Thanks!
This is a short introduction presentation for the PMOZ conference in Sydney later this year.
In May 2011 I presented this discussion of why project scope is driven by requirements, how requirements change is inevitable, and how that makes good project estimates very difficult. I then present one useful technique for managing this challenge.
I gave this to the Melbourne Scrum Users Group. It was an interesting group with a few experience scrum users and many inexperienced people via the ACS, so the talk had to accommodate some Scrum 101 stuff, and went longer than planned with me talking for a bit over an hour. In the end it went well, and I hope I get some feedback from the audience via the meetup site and ACS website.
When Business Analysts take their analysis and recommendations to stakeholders, we often use workshops. There is a trap in the workshop. You can only fit so much communica
Where are we 18 months after the teams adopted scrum. Where do we want to go?
a presentation on how a business analyst can fit themselves into an agile/scrum project. Comments very welcome.
Using Kano Analysis to prioritise Business Requirements Noriaki Kano, recipient of the Deming Prize, developed a model to work out what stakeholder requirements are mandatory, which ones are value for money proposition (i.e. more is better,) and which requirements will delight them. This talk introduces the Kano model in the business/software requirements context, and presents a step by step application of the model so that you can delight your stakeholders.
Some notes on how to assess a project brief or business case proposal. Don’t buy what you hear on face value.
A guide on how to review and give feedback to business requirements documents for software projects.
A summary of the more popular software develpment processes and methods.
Wrapping up the intor to project management series with a skim across some conemparary issues.
Some thoughts on the challenges of goal alignment between consultants and clients
A wide ranging discussion on issues surrounding the globalisation of the project workforce
How to monitor your project once it’s underway. Is it going accoridng to plan?
About managing conflict within the team and beyond. Useful info for project managers of all sorts.
About managing teams in a project context
Posts
Melbourne Agile and Scrum User Group
Details of this workshop are via the Agile Business Analyst meetup. Please sign up at that meetup if you are coming.
Melbourne - Australia
Wednesday, February 15 at 5:45 PM
Attending: 1
Details: http://www.meetup.com/scrum-12/events/51675792/
Melbourne Agile and Scrum User Group
Dean Leffingwell is presenting at Telstra Theatre. Please sign up at Agile Australia if you want to attend.
Melbourne - Australia
Wednesday, February 15 at 6:00 PM
Attending: 1
Details: http://www.meetup.com/scrum-12/events/51675852/
Melbourne Agile and Scrum User Group
This month the group talks about common smells and anti patterns. We will have a short intro sharing the concept of scrum smells and then open questions and discussions to a panel.
Some of our volunteer panel members are;
- Erik Petersen
- Bruce Taylor
- Reg De Silva
- Neil Killick
- (Anyone else? Just edit yourself in here)
You might also like to check out this wiki on scrum smells!
Melbourne - Australia
Wednesday, February 29 at 6:00 PM
Attending: 35
Details: http://www.meetup.com/scrum-12/events/47307282/
Melbourne Agile and Scrum User Group
Dom Fenton talks about Scrum.
This presentation is aimed at introducing new people to Scrum and reminding more experienced practitioners of how important the basics really are.
The presentation will be followed by a Q&A session facilitated by Dom and several other experience scrum professionals.
Dom is a project leader with experience both across Europe and locally with several of Australia's largest corporations. He is currently leading an agile team at Telstra.
Melbourne - Australia
Wednesday, March 28 at 6:00 PM
Attending: 14
Details: http://www.meetup.com/scrum-12/events/44154082/
Melbourne Agile and Scrum User Group
TBC. Suggest a topic
Melbourne - Australia
Wednesday, April 25 at 6:00 PM
Attending: 1
Details: http://www.meetup.com/scrum-12/events/cmtvtyqgbhc/
Melbourne Agile and Scrum User Group
TBC. Suggest a topic
Melbourne - Australia
Wednesday, May 30 at 6:00 PM
Attending: 1
Details: http://www.meetup.com/scrum-12/events/cmtvtyqhbnc/
Melbourne Agile and Scrum User Group
TBC. Suggest a topic
Melbourne - Australia
Wednesday, June 27 at 6:00 PM
Attending: 1
Details: http://www.meetup.com/scrum-12/events/cmtvtyqjbkc/
Melbourne Agile and Scrum User Group
TBC. Suggest a topic
Melbourne - Australia
Wednesday, July 25 at 6:00 PM
Attending: 1
Details: http://www.meetup.com/scrum-12/events/cmtvtyqkbhc/
Posts
Agile Business Analysts, Melbourne
At this month's meet-up we review the concept of the Story Map, per Jeff Patton's model. We will also discuss how other analysis models can also provide a framework for sorting and categorising user stories.
The session agenda will look something like this:
- Introduction to the topic: 15 minutes
- Break into groups and generate a story map from your projects or a fictional case study: 30 minutes
- Review groups outcomes and share learnings: 30 minutes
Melbourne - Australia
Wednesday, February 15 at 6:00 PM
Attending: 39
Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/46913642/
Agile Business Analysts, Melbourne
Shawn Callahan of Anecdote comes and shares some stories about storytelling and the importance of narrative when we communicate with our business partners and peers.
The Anecdote approach to corporate storytelling is relevant to agile business analysts because it is built upon the ideas of facilitation, discovery, alignment and evolution. And stories!
The format of this will be a facilitated discussion by Shawn.
Also take a look at how good story elicitation helps businesses be more effective here.
Melbourne - Australia
Wednesday, March 14 at 6:00 PM
Attending: 14
Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/47390112/
Agile Business Analysts, Melbourne
Software Education is bringing Alec Sharp to Melbourne for a Masterclass in Business Process Management and he has kindly agreed to present to the Agile & Scrum meetup.
Alec is extremely informative and always entertaining. Come along and hear what he has to say about Modelling in an Agile world.
Summary below;
Agile, or something like it, had to emerge. Think about some of the alternatives – voluminous BRDs (Business Requirements Documents) with literally thousands of itemised (and useless!) requirements. Or excruciatingly detailed models, incomprehensible to mere mortals – even the people who built them.
Getting away from these approaches was a good and necessary move. But did the pendulum swing too far? Have we abandoned some modelling techniques that would be useful in an Agile environment, possibly making it even more Agile?
Some Agile teams think so, and have found that by using the right techniques, at the right level of detail, at the right time, they’re seeing real benefits – better engagement from their clients, and fewer iterations.
This presentation will describe a distinctive framework utilising four, interrelated perspectives - process workflow models, a unique form of use cases, business services, and business-friendly data models.
Special attention will be paid to providing guidelines and tips for making process and data modelling useful to Agile teams. Topics will include:
• Why use cases should be separated into use cases and business services
• How data models provide a great platform for discovering and understanding use cases and services
• How workflow models provide context for use cases, and help make sense of “epics”
• What does “just enough” modelling in an Agile environment look like?
Melbourne - Australia
Monday, March 26 at 7:00 PM
Attending: 26
Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/49224732/
Agile Business Analysts, Melbourne
A debate investigating what agile means for the role of a business analyst.
Is business analysis a competency or a role on an agile team.
Kevin Broughton will be hosting a debate exploring what happens to a BA in an agile world. Two sides will debate two perspectives and the questions and comments will be opened to the audience.
What's your experience? How do you think this role debate should play out? Come along and participate in the discussion.
We have opened a discussion thread to support this debate.
This month's meetup is a great opportunity to bring 'non-BA' colleagues to help them understand the contribution analyst make (or don't make.) Bring a friend.
Light refreshments will be available.
Melbourne - Australia
Tuesday, April 10 at 6:00 PM
Attending: 5
Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/49698302/
Agile Business Analysts, Melbourne
Melbourne - Australia
Tuesday, May 8 at 6:00 PM
Attending: 1
Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/cmkvvyqhblb/
Agile Business Analysts, Melbourne
Melbourne - Australia
Tuesday, June 12 at 6:00 PM
Attending: 1
Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/cmkvvyqjbqb/
Agile Business Analysts, Melbourne
Melbourne - Australia
Tuesday, July 10 at 6:00 PM
Attending: 1
Details: http://www.meetup.com/Agile-Business-Analysts-Melbourne/events/cmkvvyqkbnb/
Profile
Summary
Highly motivated, experienced and skilled program, project consultant.
Able to build trust and consensus across diverse teams and deliver outstanding results in even the most challenging project contexts.
Loves discovering great teams and building communities.
Fascinated by business models.
Wants to help you elevate your team's performance to higher levels.
Experience
- Jul 2011 - PresentHead of Project Management & Assurance / Swinburne University of TechnologyI manage the project delivery capability at Swinburne's IT department. This includes project managers, business analysts, quality analysts and testers.
I am also engaged in working with business partners to the IT department to help increase overall project and product delivery capability. - Jul 2011 - PresentOccasional Agile Trainer @ Telstra / AccentureParticipating in the agile adoption at Australia's largest telco.
- Jan 2008 - PresentDirector / Evaluator.com.auConsulting business that helps you understand how to improve your project and technology performance.
- Oct 2010 - Jun 2011Consultant / Business Analysts Pty LtdI worked with organisations to increase their project capability through systematic improvements to process, systems and tools. I also coach with people on BA and PM techniques and methods and also help out on projects at a practical level.
- May 2008 - Nov 2010Program Manager / Workcover NSWManaging strategic program updating business models, replacing legacy IT systems with both in house and vendor delivered solutions, and implementing Scrum along the way.
- Mar 2008 - Jul 2010Lecturer / Melbourne Institute of TechnologyLecturer in Project Management to Masters degree students.
- Apr 2008 - May 2008Consultant / St George BankProject recovery and strategy work.
- Jul 2005 - Feb 2008Project Consultant / OptimiseITProjects I worked on at ANZ Mortgages included;
- Strategic planning
- Major IT programs
- Enhance corporate web site (sales channels)
- Six Sigma projects
- Training and coaching staff - Jul 2005 - Dec 2007Project Consultant / ANZWorking via OptimiseIT
- Dec 2006 - Apr 2007Project Manager / Telstra BusinessManaging new products to launch for Testra's business customers.
- Sept 2003 - Feb 2007Director / erina legalErina Legal is a law firm based upon the Central Coast of NSW.
The practice areas are Family Law, Property Law (especially conveyancing), Business Law, and Wills and Estates. - Dec 1997 - 2005Various roles / OptusProject Manager, Manager of the Business Process Improvement (BPR) Team, Business Analyst, IT Management, Technical support.
For me, Optus was several years of working with great people on cool projects.
Education
-
2005 - 2007RMIT UniversityMasters in Project Management
-
1990 - 1994University of NewcastleBachelor in Business
-
1983 - 1988Henry Kendall High School
Additional Information
Posts
The Victorian State Ombudsman tabled his report titled “Investigation into ICT Enabled Projects – November 2011” in which he analysed the performance of 10 high-profile publicly financed projects. The findings of the Ombudsman’s report are fascinating and today I would like to focus, in a bullet point and short format, on his findings as relate to the Myki project.
- A 2004 Business Case by the Transport Ticketing Authority (TTA) forecasted total expenditure of $741.9 million over the life of the project (2004-17).
- Project costs revised up to $999 when a vendor was appointed to develop the system in 2005.
- In April 2008, the budget was increased to $1.35 billion (an increase of 35% in just under 3 years).
- Under the terms of the original contract, the system was to be fully operational by July 2007. Full implementation is yet to be achieved and the project is some four years behind schedule.
- Until two years into the project (when the project failed to meet its two years delivery deadline) the board of the TTA had a single board member with relevant ICT projects’ experience.
- In the initial evaluation of the six tenderers, only the successful bidder was unable to evidence a proven solution: all others nominated sites where their solutions were in place.
Corruption or stupidity? Either way the cost will be covered using my tax money.
For more information regarding the general trends associated with Transportation Infrastructure projects read my earlier post on Bent Flyvbjerg’s research on Cost Overruns in Transport Infrastructure Projects.
Hiya
I have been wrong about many things – I am happy to admit that. In SharePoint land, one of my bigger naive assumptions was that in early 2007, I figured I’d have maybe a 6 month head start before the rest of the industry began to learn from its initial SharePoint deployment mistakes and start delivering SharePoint “properly.” I thought that I’d better make hay while the sun shines, so to speak, as the market would tighten up as more players entered it.
Yet here we are, heading to the latter half of 2011 – some five years later. As I continue to go into organisations, whether in a SharePoint remedial capacity, or a training/architect capacity, I am still seeing the legacy of really poor SharePoint outcomes. Furthermore I am seeing other, frankly disturbing trends that leave me both concerned and pessimistic. I now have a label for this concern: “SharePoint Fatigue Syndrome.” SharePoint Fatigue Syndrome is hard to define, yet its effects are there for all to see. I suffer from it at times, and I am certain others do too. As an example, recently on the Perth SharePoint User Group on LinkedIn the following topic for discussion was raised:
Hi folks, as you already know we have a worrying skills shortage in SharePoint Development / Architecture in Perth and things are getting worse. It’s getting to the stage where companies have to suspend or worse still abandon their SharePoint projects due to lack of available talent. As the core of the SharePoint community in Perth your suggestions are vital towards finding real solutions to this growing problem. What can be done?
Now I know that this problem is not just limited to Perth. There are consistently reports online that speak of SharePoint people being in demand. So you would think that in a “hot” sector like SharePoint, where the industry is crying out for talent, that the rate of attrition would not outpace the uptake of new talent. After all – money talks, right? If you are a .NET developer with half a brain, there is serious money to be made in SharePoint development land. On top of that, there is the collective realisation in the marketplace that actually talking to people about how SharePoint could make their lives easier, leads to better outcomes. Hence the emergence of this notion of a “SharePoint Architect” with a more varied skill-set that just tech or dev. This role has further been legitimised by entire conferences now just catering to the business this end of the market (I am thinking the Share conferences here).
So, we have all of this newfound collective wisdom spreading through the community via various channels, in terms of the skills and roles required in SharePoint circa 2011 and beyond. We have the fat pay-packets being commanded as a result of demand for these skills. So, with that in mind, why is the attrition rate growing?
As an example, I know personally, several exceptional SharePoint practitioners who are no longer in SharePoint. I’ve also had various quiet conversations with many SharePoint practitioners, right up to SharePoint MCM’s, who vent their various frustrations on how difficult it is to get truly lasting SharePoint solutions in their clients and organisations. I’ve reflected on the various reasons I have come to the conclusion that SharePoint is just plain tiring. As a result, people are burning themselves out.
7 causes of SharePoint Fatigue Syndrome…
Burnout, in case you are not aware, is actually a lack of emotional attachment to what you are doing. Quoting about.com:
The term “burnout” is a relatively new term, first coined in 1974 by Herbert Freudenberger, in his book, “Burnout: The High Cost of High Achievement.” He originally defined ‘burnout’ as “the extinction of motivation or incentive, especially where one’s devotion to a cause or relationship fails to produce the desired results.
SharePoint Fatigue Syndrome is SharePoint manifested burnout. The symptoms include feeling physically and emotionally drained, difficulty maintaining optimism and energy levels, feeling that you have less to give as the burden of work seems overwhelming. Sound familiar?
So why does SharePoint work run this risk? I see 7 major reasons.
1: Cost pressure leading to overwork
First up, the lure of the big dollar is a double edged sword. Not long ago I shared a beer with a SharePoint developer who’s work I respect greatly, yet I can’t afford to hire. This is because the percentage of chargeable hours he would need to work just so I can break even, is very high. This puts me (the employer) under pressure and at risk. As a result, I need to ensure that my newly minted SharePoint employee is productive from day 1 and I need him to work a lot of hours. But here is the irony. When I had my beer with this developer, the conversation started with him lamenting to me that he is already pulling ridiculous hours (60 to 80 per week). He was looking for a job with less hours and yet more money. This is simply not sustainable, both for employer and employee. The more you chase one (work hours vs. money), the more you lose the other it seems.
2: Structures that force an inappropriate problem solving paradigm (and wicked problems of course)
Then there is the broader problem where structure influences behaviour. As a basic example: from the developers’ perspective, they have to put up with sales guys who promise the world, and project managers who then make their life hell and force them to cut corners delivering the impossible. Project managers find out that their beloved work breakdown structure gets chopped and changed when their pain-in-the-ass developers whine that they can’t make the schedule. As I have stated many times previously, SharePoint project are likely to have wicked problem aspects to them. The structures that work well to deliver tame problems, such as Exchange, a VOIP system or a network upgrade, are much less effective for SharePoint projects. While organisations persist with approaches that consistently fail to deliver good outcomes, and don’t look at the structural issues, the attrition rate will continue. There is only so much that someone can take putting up with these sorts of stresses.
3: Technical complexity
SharePoint’s technical complexity plays a part too. No-one person understands the product in its entirety. The closest person I know is Spence and ages ago on twitter he remarked that even within Microsoft no-one understood it all. As a result, it is simply too easy to make a costly mistake via an untested assumption. (I thought the user profile service was tough – until I did federated claims authentication and multitenancy that is). The utter myriad of features, design options and their even greater number of caveats, mean that one can make a simple design mistake that causes the entire logical edifice of an information architecture to come crashing down. Many have experienced the feeling of having to tell someone that the project time and cost is about to blow out because nobody realised that, say, Managed Metadata has a bunch of issues that precludes its use in many circumstances. Accordingly, SharePoint architects learn pretty quickly that it is hard to answer a definite “yes” to many questions, because to do so would require a question worded like a contractual clause, to ensure it is framed with appropriate caveats. Even then, consultants would know that lingering feeling in the back of their mind that they might have missed an assumption. This brings me onto…
4: Pace of change
This is BIG…and becoming more acute. Remember the saying ‘The only certainties in life are death and taxes?’ Outside of that, the future is always unpredictable.
In between SharePoint 2003 and SharePoint 2007, the wave of Web 2.0 and social networking broke, forever changing how we collaborate and work with information online (and some of those effects are still to be felt). Microsoft, like any smart organisation, responds to the sentiment of its client base. Microsoft also, like most mature organisations, tends to hedge its bets in terms of marketplace strategy in which it tries to get in on the act with the cool kids, yet tries not to kill the goose that laid the golden egg. Just look at Windows 8’s new interface, tablets, app stores and the cloud.
But that is one facet. Change happens in many forms and at many scales. For example, at a project level, it may mean a key team member leaves the organisation suddenly (SharePoint fatigue no doubt). At a global and organisational level, events like the odd global financial crisis force organisations to change strategic focus very quickly indeed.
I don’t know about you, but when Windows 8 was announced recently I was not excited (in fact I was not excited by SharePoint 2010 either). I thought to myself “So soon? I am still figuring out the current platform!”
As an example of the effect of pace of change, consider all the Government 2.0 initiatives around the world. Collaboration is in-vogue baby, so information should be free and government agencies should engage with the community. While that’s nice and all, there is the world of compliance, security and records management that takes a very different view. So, we end up with market forces that push against each other in combination with vendors hedging strategy of being all things to all people. It’s little wonder that SharePoint projects become very complex very fast.
By the way, it is worthwhile checking out what Bill Brantley in this post sums up the whole government 2.0 issue when he said:
What exactly is the nature of the Gov 2.0 challenge? This question was inspired by Andrew Krzmarzick’s post (What Gov 2.0 Needs Now: Managers, Money and Models) and Christina Morrison’s post (What is Gov 2.0? A survey of Government IT pros) on the recent GovLoop survey about Gov 2.0. As Andrew and Christina argued, the survey demonstrates many differing perspectives on Gov 2.0 in terms of what it actually means and how to implement Gov 2.0. To me, this suggests that Gov 2.0 is the classic wicked problem
5: SharePoint Entropy
One of my clients (who you will meet in my book when it’s published), once said to me “All good ideas eventually deteriorate into hard work.” This is a nice way to lead into the concept of SharePoint entropy, which in some ways is the inevitable outcome from the first four symptoms. The easiest way to understand entropy is to watch this awesome TV series called the “Wonders of The Universe.” In that show, the concept of entropy was discussed and for me made a lot of intrinsic sense. Without getting into the detail, entropy is the notion that over time things move from an organised to less organised state. Rather than have me waste your time trying to explain it in prose, let’s listen to the show in question. (Don’t skip the video – this is important!)
Now what does this has to do with SharePoint fatigue? Gordon Whyte saw what I am getting at with his post on entropy within organisations, especially in relation to change management.
For example, when we build a car we take raw materials such as metal, leather, plastic and glass and arrange them in a highly organised way to make a car. But if we then leave that car for long enough the metal will rust, the glass will become brittle and break and the leather will dry out and turn to dust. If the car is left for a very long time it will eventually disappear altogether. This thought left me wondering about the nature of organisations. If a progression from order to chaos is the natural order of the universe, then is this same pressure present in organisations and, perhaps more importantly, what is the optimum position for an organisation between the extremes of rigid inflexibility (low entropy) and complete chaos (high entropy)? This question is not as crazy as it might at first appear”
Gordon has nailed the issue in his post. Any SharePoint solution that has a low entropic nature requires more energy and effort to maintain that order and control. Complex SharePoint solutions often have complex governance wrapped around them. Governance that is process and structure centric by definition, has low entropy and accordingly, needs higher effort to maintain over time. In fact, if you do not maintain that effort and energy, then any SharePoint solution will usually disintegrate back into the sort of information management chaos that gave rise to SharePoint in the first place! Rather like the sandcastle in the video.
By the way, I feel that email and file shares are high entropy solutions – all failed SharePoint projects lead back to these tools because they require less structure to maintain (in the short term).
In short, if SharePoint is implemented with low entropy, more energy is needed to maintain it. Remove the energy and very quickly, things become chaotic again. Governance approaches that are not cognisant of this will never stand the test of time. The question then becomes whether people feel that the end in mind is worth the perceived extra effort that is being asked of them.
6. Social complexity
Social complexity is also somewhat of a result of the first five symptoms. Most organisations have a blame culture. If they didn’t, then people wouldn’t spend so much time trying to position themselves for blame avoidance. Social complexity is the result of turf wars, ideological smackdowns and all of the other sort of things that result in the cliché of “the silos” where people are not talking to each-other in organisations. SharePoint exacerbates social complexity for two main reasons.
Firstly, because it is a collaboration tool, it actually requires some collaboration to put it in! This is often easier said than done. Secondly, because it is a pervasive and disruptive technology, it almost always clashes with an established tool, process or practice where proponents aren’t willing to change. In fact, they may not even recognise that there is a problem to solve – especially when SharePoint has been thrust upon them. (In an old post, I wrote about the notion of memeplexes and the ideological immune mechanisms that they create and why it is so hard to get shared understanding across departmental boundaries in organisations. Memetic smackdowns are the result).
The long and the short of social complexity is that there is only so much stress people can take. We all seem to have a pathological need to seek order and safety, rather then remain in a stressful situation. Once social complexity bites, the merry-go-round of staff attrition really starts to bite…
7. Meaning over motivation…
Now if I haven’t completely depressed you, let me offer you a perverse glimmer of light. For those of us who understand the preceding 6 fatigue symptoms, recognise them for what they are and take steps to mitigating them, there is one other symptom that contributes to SharePoint Fatigue Syndrome. This is the trickiest of all – and I am a somewhat willing victim of it.
I have spent a lot of time learning techniques to help address the symptoms I outlined here and as it turns out, these skills are universally applicable, whether in SharePoint, IT or beyond IT. For years now, I have metaphorically had one foot out of the SharePoint world door and the other foot into the world of construction, health and management sectors. Hell…I have written what I think is the first business book ever by a SharePoint person that is a non SharePoint and non IT. I also have clients with SharePoint deployments who do not know me as a SharePoint person at all, but only as a sensemaker (and for that I am grateful.)
The point is this: While the investment in these skills enables me to counter the effects of SharePoint fatigue syndrome, it is also inexorably pulling me away from SharePoint work. It seems that once you crack this nut a little, your skills are in demand across the entire problem solving spectrum. Right now this is my coping mechanism for SharePoint Fatigue Syndrome – I get to step away from SharePoint for periods and work on something else. Eventually…inevitably…I will also be one of those attrition statistics.
Conclusion:
The problem is that SharePoint Fatigue Syndrome is a negatively reinforcing cycle. As evidenced by the SharePoint attrition rate, money isn’t that great a motivator. If it was, then the void of skilled resources would have been filled by now. Paying more money might give you a short term gain, but in the long term is not going to address my seven causes of SharePoint Fatigue Syndrome.
I will leave this admittedly negative sounding post with the key to breaking this cycle. While you can attend my SharePoint Governance and Information Architecture class or Issue Mapping Class to learn many ways, the video below says it all. I encourage you to watch and reflect on it, because it’s the same key point to understanding how to do effective user engagement.
Thanks for reading
Paul Culmsee
No Tags
In their new book, Beyond Performance: How Great Organizations Build Ultimate Competitive Advantage, Scott Keller and Colin Price identify nine factors that are critical to organizational health: Direction, Accountability, Motivation, Leadership, Coordination & Control, External Orientation, Culture & Climate, Capabilities, Innovation & Learning
Organizations that thrive over the long run, in good times and bad, pay explicit attention to all these issues. Three of them, though, seem particularly crucial as we think about new challenges confronting us today.
Motivation: As products, services and even knowledge itself get commodified ever more rapidly, we need organizations that are capable of producing a steady stream of highly differentiated products and services. This requires imagination, which is, in turn, the product of passion. In business as in other aspects of life, passion is the difference between "insipid" and "inspired." Innovation doesn't come from dispirited employees.
Amazing contributions don't come from employees who feel like conscripts. Therein lies the problem. By one recent estimate, only 14% of employees around the world are highly engaged in their work. This has to change. We must be as rigorous and inventive about inspiring passion and unleashing contribution as we are about every other aspect of business.
External orientation: In our hair-trigger economy, customer preferences change at light speed. Unexpected new challenges can pop up at any moment, and new opportunities come and go quickly. The environment for business is more dynamic, more complex, and more global than ever. Given that, we need organizations that can draw meaningful insights out of the maelstrom of fragmentary and incoherent data that daily surrounds them. We need companies where every individual is equipped to sense emerging trends, where the implications for action are rapidly recognized, and the necessary resources are quickly brought to bear.
The decision lags typical of large, bureaucratic organizations are becoming untenable. Individuals on the front lines must have the discretionary power to respond instantly to shifting circumstances. Rather than moving information up to those with authority, authority must be pushed down to those with real-time information.
Coordination & Control: With global supply chains, distributed production networks, and virtual teams, the challenges of coordination are more pressing than ever. In most organizations, managers are the rivets that hold everything together. They connect activities, teams, programs, and business units. The implicit assumption: coordination requires a hierarchy of coordinators. Problem is, hierarchy adds costs and reduces responsiveness. What's needed now are ways of integrating complex activities with little or no management overhead.
And then there's control. Managers are often the enforcers. It's their job to ensure that procedures are followed, budgets are met, and slackers are punished. But again, a supervisory superstructure is expensive and profoundly disempowering. We need organizations where control comes less from rules and sanctions, and more from norms and peers. We need to radically reduce the management costs associated with both coordination and control.
Hence The Beyond Bureaucracy Challenge, the second leg of the HBR/McKinsey M-Prize for Management Innovation. Help us build organizations that are fundamentally fit for human beings, characterized by:
Total Passion: We know a lot about what it takes to drive deep engagement: purpose, self-direction, a sense of community, and opportunities to grow are a few of the most important. What we're looking for are examples where engagement has been taken to new heights, where management assumptions, processes, and behaviors have been radically overhauled in ways that create a sense of adventure, that inspire leaps of imagination, that foment excitement, and take the work out of work. If you don't have a real-world case to share, invent a hack — a bold, new idea for turning contented team members into zealous ones.
Outside-In: How can we turn an entire organization into a sensory organ, ever alert to the changing dynamics of the marketplace? How can we dramatically improve the signal-to-noise ratio in environment scanning? How can we ensure that weak signals don't get filtered out when the implications are politically uncomfortable? How can we eliminate the lags between "sense" and "respond?" How do we mobilize teams and resources faster than ever? And how can we inject the voice of the customer into every decision? More generally, how can we create organizations where a lot fewer people are inward-focused and a lot more are outward-focused and where contributions at the edges are every bit as important as those emanating from the center? Once again, we're looking for game-changing practices and mind-flipping hacks.
Managing without Managers: Managing is largely about controlling and coordinating. Can the work of managing be pushed out to the periphery of our organizations? Can it be automated? Can it be dispensed with entirely? Is it possible for an organization to be highly decentralized and precisely synchronized? Can you get discipline without disciplinarians? Are there ways of combining the freedom and flexibility advantages of markets with the control and coordination advantages of traditional hierarchies? Can we reduce the performance drag of our top-heavy management structures without giving anything up in terms of focus and efficiency? To what extent can "self-management" or "peer-management" substitute for "manager-management?" If you've got some hard evidence, or just a wild idea, share it with the world.
Help us turn healthy organizations into world-class athletes that are able to vault over tomorrow's challenges. Learn more about participating in the challenge at the MIX.
Awards are a very interesting thing, especially the motivation for giving them. I’m particularly uneasy about the UK Agile Awards, which ran for the second time this year with the results being announced a few weeks ago. As far as I can tell pretty much all of this years winners have a relationship with one of the sponsors. Lets go through each of the winners and see:
Agile Project or Programme Manager of the Year: Chris Berridge
Works for Emergn, who were a sponsor.
Edit: Correction, Chris works for Maersk, who worked with Emergn, who were a sponsor.
Best Agile Project or Innovation: ”Fixing the Flaws in Government IT” – The IfG Report
IfG worked with Indigo Blue closely on the report, who were a sponsor.
Agile Consultancy of the Year: Indigo Blue
Who were a sponsor…
Best Agile Team: The Guardian
Worked closely with Indigo Blue on their major redesign a year or so back, who were a sponsor.
Most Agile Aware Organisation: Simply Business
Not found a link, but not looked that hard. Anyone?
Edit: As per Paul’s comment below Simply Business are associated with Emergn, who were a sponsor
Most Engaged Management Team: IPC Media
A sponsor…
Best Use of Agile in the Public Sector: DWP
Working closely with Emergn, who were a sponsor. I also find this one particularly irritating as they haven’t even delivered anything yet! As one of the principles of the Agile Manifesto states, “Working software is the primary measure of progress.”
Best Use of Agile in the Private Sector: BSkyB
Not found a link, but not looked that hard. Anyone?
Best Agile Coach/Mentor: Dot Tudor
Works for TCC, who were a sponsor.
Most Valuable Agile Player (UK)
Keith Richards, who was a sponsor.
I’ve no doubt that some of these organisations were approached after they were nominated, but looking at who the sponsors were for the previous year it’s mostly the same faces. Hmm.
Well… if it’s that easy then I hear by announce the Rob Bowley “Agile as Fuck” Award and the winner for 2011 is…
ME!
A year ago I bought the book “Visual Meetings” (doodling for team productivity) and a Moleskine notebook (of course) on my way back from Washington to Amsterdam. At the stopover in New York I drew this:
And this:
It changed my work. Really.
Before I just had a stack of Moleskine notebooks (what else) full of seemingly unrelated notes. Words. Lots of words.
I knew there was a pattern. Somewhere.
But connecting the dots got just more difficult. Making more notes made things worse. Not better.
So. I started doodling. Making awful simplistic drawings. And I am sharing these drawings. Not to show off my skills. It is more to show you it’s ok if you can only doodle and not create picture perfect images.
This is what I found.
If you make a lot of drawings, a common visual language emerges. You use several symbols over and over again. The use of identical symbols reveal a hidden link.
After the individual images I crafted a “story”. On the topic I find most difficult. Identity. Ok. I also used text and quotes.
I created many pages to explain to myself the things I had written over the last years.
This helped me immensely in explaining this stuff. To you and to myself. Mainly that last part.
It changed my approach to almost every thing that feels complex and appears difficult.
As always. You don’t have to try this. Really.
But before you decide, I hope you have a look at this short (5mins) TED talk by Sunni Brown, author of “Gamestorming”. Doodlers, unite!
Bas de Baar helps people find ways to enjoy the diversity of human interaction in their projects and organizations so that they can get out of their own way and achieve their goals. - Connecting The Dots With Doodling. Making Complex Things Less Complex. is a post from: Project Shrink.
Here is a video of my presentation on challenging requirements, filmed at AgileEE last week, filmed by someone from the audience.
Here is a video of a recent session on effect mapping at the Agile testing UK user group. I introduce effect maps, then Jenny Martin and Kate Warner from Loyalty Management talk about how they applied it in their company, then David Evans presents some ideas on how to improve testing by extending the maps.
For years critics have raised alarms about higher education: rapidly rising tuition costs without corresponding increases in value, a trillion dollars of student debt, compromised access, country club tenure for academics, decreasing relevance of tuition to the real world, among other issues.
The Innovative University
Now Clayton Christensen, the father of the theory of disruptive innovation, and his colleague, Henry J. Eyring, in The Innovative University: Changing the DNA of Higher Education from the Inside Out (Jossey-Bass Higher and Adult Education Series) (Jossey-Bass, 2011) tell the stories of two very different universities—Harvard and BYU-Idaho—and how they are addressing innovation in higher education.
The two universities have an interesting link in that in 2005 the highly successful Dean of Harvard Business School, Kim Clark, surprised everyone by leaving his posaition at Harvard to become the president of BYU-Idaho. BYU-Idaho? Most of his colleagues had never heard of it. The book tells how Clark went about reforming a traditional university, showing his successes as well as the roadblocks he ran into.
After a lengthy examination of the histories of these two very different universities, they discuss how these universities are exploring innovative, less costly ways of performing their uniquely valuable functions and thereby save themselves from decline.
Online education
In particular, the book advocates that colleges and universities embrace online education. It argues that online technology makes a college or university vastly more attractive to a wide subset of students. It gives many people a second chance at learning – i.e. those who cannot afford a traditional college education, those who do not have the flexibility to take part in a full plate of coursework, and late bloomers or dropouts who have fallen behind and now have the chance to catch up. But online learning doesn’t just offer cheaper education for the masses. It improves the student learning experience across the spectrum by allowing students to learn at their own pace and on their own timetable.
Q&A with the authors
I talked recently with the authors about their book.
- The book discusses at length the history and evolution of two important but very different universities, Harvard and BYU-Idaho. What do you see as the respective strengths and weakness of these two universities today?
Harvard of course excels in its reputation, faculty, wealth, and alumni network. Its few significant weaknesses include organizational complexity and high operating cost. The high cost derives from traits of the traditional research university, such as faculty who spend a relatively small percentage of their time in the classroom and a campus that sits largely idle during the summer. Also, Harvard has invested heavily in a system of residential housing and high-quality tutoring. This means that even students who pay the tuition sticker price aren’t covering the full cost of their education. Thus, growing the size of its “customer” base, which is how businesses achieve scale economies and greater profitability, is financially problematic for Harvard and for other universities with similar operating models. The number of students they can serve is limited, not because they don’t have enough qualified applicants, but because they can’t afford to subsidize additional students.
BYU-Idaho’s strengths include a low-cost operating model, which derives from (1) faculty focus on undergraduate instruction, (2) year-round operation, and (3) use of online learning technology. A “Learning Model” common to all courses promotes consistent learning quality, even in online offerings. BYU-Idaho’s ongoing challenge is to ensure learning quality by rigorously defining and measuring learning outcomes and continuously improving the curriculum.
2. What is the purpose of a university as depicted in this book? Is it: A. A university is an institution that provides a degree, which is a credential or screening device for the economy and for society? Or B. A university is an institution in which people acquire the knowledge they need for a particular job? Or C. A university is an institution in which people acquire the knowledge they need to be a citizen? Or D. A university is an experience where you acquire a capacity to be a lifelong learner (because most of the knowledge you acquire will be obsolete within a few years and the jobs of tomorrow will not be the jobs of today)? Or E. Something else?
Ideally, a university or college education serves all four of these purposes. The degree is the easiest to provide, and the types of knowledge listed above are sequentially more difficult to impart. That becomes increasingly true as the world grows more complex.
3. Some have argued that goal #2. D. (a capacity for lifelong learning) should be the most important purpose, given the highly dynamic state of today’s economy. Do you think the book gives enough emphasis to that? How good a job are these two universities doing at that?
The book doesn’t directly address the importance of lifelong learning. However, it describes learning approaches, such as BYU-Idaho’s Learning Model and Eric Mazur’s use of peer-to-peer instruction at Harvard, that prepare student for lifelong learning. One of the best ways to learn to learn is to be an active learner and a teacher of one’s fellow students in college.
This instructional philosophy isn’t yet widespread, but its effectiveness has been proven, and it doesn’t require additional financial investment, only a change in the attitudes of faculty members and students. Broader adoption seems likely, with time.
4. The book says that in performing its purpose, a university has three “jobs to do”: discovery, memory and mentoring (p.335). Could you explain this framework?
Traditional universities do three valuable things that other institutions don’t. All three require talented faculty members with scholarly training. These things are (1) discovering and disseminating new knowledge, (2) preserving the discoveries of the past, and (3) personally mentoring students in ways that allow them to participate in (1) and (2). Doing these things well takes special training. It is inherently expensive, because the processes involved are hard to automate or even systematize very much. Still the value is great, and society needs universities to do these “jobs.” The trick is to get the jobs done at a price that students and society can afford.
5. The book gives both universities generally high marks for discovery and memory of knowledge. How does this fit with the recent realization that several decades of foreign outsourcing by the private sector have resulted in the loss of knowledge related to huge sectors of the economy, particularly those that crucial for the economy’s future, with no obvious way to get that knowledge back to this country? What role do you see for universities in preventing further loss of knowledge that is crucial for the country’s future?
Economic and social globalization makes the traditional university more valuable than ever. Unlike most for-profit organizations and even governmental institutions, the university is designed to be global in its pursuit and preservation of knowledge. Thus, a nation that invests in effective research universities can worry less about the specialization that inevitability occurs as it focuses on the industries and value-adding activities in which it is most competitive. This won’t happen without thoughtful direction and coordination, but nations with outstanding university systems will continue to enjoy a competitive advantage. These nations can specialize their activities without losing touch with the full range of knowledge needed to be world leaders.
6. Some have argued that the ability to ask the right questions is today as important as and possibly even more important than a capacity to give the right answers. How well do these two universities do in responding to that challenge?
As mentioned in response to question 3, Harvard and BYU-Idaho involve their students in teaching one another. They also have general education courses, created in the last five years, that cut across academic disciplines and engage students in applying principles and theories to real-world problems. These instructional approaches challenge students to frame inquiries, rather than merely respond to questions posed by their professors. More can be done, but Presidents Derek Bok and Kim Clark, who championed the new GE programs and learning models at their respective institutions, helped their schools go a long way toward graduating students who can ask good questions.
7. The book praises BYU-Idaho for holding costs more or less constant for an in-person degree, i.e. preventing further cost increases (p.300) and cutting costs of an online degree by 75% (p.317). The book gives less information as to what Harvard has done to control costs. Do you think these efforts at cost control are adequate, given that student debt in the USA is now around $1 trillion and growing rapidly?
We all need to be looking constantly for ways to do more with less. Fortunately, new learning technologies make that possible. But Harvard and other elite institutions are in a paradoxical position. Their students and alumni are satisfied with their current offerings; in fact, they have a huge surplus of qualified applicants. They are exploring and investing in new learning technologies, and they have the capacity to use that technology to serve more students at lower cost, if they choose. The question is when and how to change in ways that won’t detract from the quality of what they already do.
We’re likely to significant change in the next decade, the net effect of which will be more students served at a lower average cost. However, the nature of the evolution will differ among institutions. The elite schools will hybridize their courses not primarily to reduce cost or grow enrollments, but to better serve the rising generation of “digital natives” and to make the most of learning-enhancing computer-adaptive technology. By contrast, schools without the benefit of high prestige and large endowments will hybridize and offer fully online courses mainly so that they can keep tuition affordable, admit more students, and use the incremental revenues to plug the hole left by rising operating costs and declining state support. In all cases, students will benefit.
8. The book says that world needs more university education, not less (p.344). Could you explain what you mean here? Given the financial issues in question #6, how realistic is that?
It’s clear that some form of higher education is becoming more important to making a comfortable living. That doesn’t necessarily mean a four-year college degree, but I’m certainly challenging my children to make that their first target. As noted above, new technologies make it possible to provide a good college education at an affordable price. BYU-Idaho, for example, has online degree programs for $65 per credit, or less than $10,000 in total. Many students will be willing and able to pay more for a mixture of online and on-campus instruction. Traditional institutions will offer programs at various points along this spectrum, as for-profit institutions are already doing. We’re going to see more higher education options, more providers, and more students.
9. The book seems to suggest that tenure for life is justified for qualified academics (p.377). However philosophically sound and desirable such an approach may be, how realistic do you think this is in the current context where practically no one else in the economy has any guarantee of lifetime employment?
It’s important to clarify what we mean by “tenure.” First, its performance based: you don’t get it for life unless you perform well for life, based on regular review. Partnership in a law firm, an investment bank, or a consulting firm may be a helpful analogy. Second, the activities being performed by the tenured professor must be consistent with the mission of the institution, which for most institutions is likely to be narrower than the mission of a large research university. Most professors will need to spend the majority of their time teaching. A school that generates the bulk of its revenues via tuition will be able to afford some time for faculty research. However, that research will need to have relevance to the student learning experience, and it won’t be the driving factor in tenure decisions; teaching quality will be. Tenure based primarily on publications isn’t a sustainable model for most institutions.
10. What other questions should I have asked you?
It’s worth noting that we’re predicting a different kind of disruption in higher education than the type seen in computer manufacturing, book publishing, or music and movie distribution. Traditional university and college campuses won’t go the way of the record shop or the video rental store. Particularly for young students, a college education is a social experience requiring some amount of face-to-face interaction. The expensive investments that traditional institutions have made in brick-and-mortar facilities and full-time faculty members will always have unique value. As these institutions adopt online learning technologies, they will be able to offer the best of both worlds to students who can afford to relocate from home and pay a premium over the cost of a fully online education. Institutions that cling too long to the old model are unlikely to survive. But those that innovate quickly have a bright future.
___________________
Steve Denning’s most recent book is: The Leader’s Guide to Radical Management (Jossey-Bass, 2010).
Follow Steve Denning on Twitter @stevedenning
And join the Jossey-Bass webinar series aimed at “Killing Dilbert-style management once and for all”: Sep 22-Oct 20, 2011. The second session begins next Wednesday September 28 at noon ET. To register, go here and use discount code JBMSD.
#pmchat is an awesome weekly tweetup of project management enthusiasts. It starts every Friday at 4.30pm (GMT) with the pre-game radio show hosted by Rob Prinzo (@robprinzo) and Robert Kelly (@rkelly976). After the 15 minute webcast, the interactive hour long tweetup kicks off. Topics covered so far include managing scope, building strong project teams, and gathering requirements.
#pmchat enjoys active participation from a tight community of friendly and experienced professionals including @HELENSStudio, @dwrichy, @klkaz, @Project_Mom,@michael_greer, @irivera, @unlikebefore, @RailComm_Paola, @sewah_kram, @ColleenGarton, and @BridgePM
I hope you can join us next week
As an industry based lobby group we were faced with Legislation to reduce government funding by $1.9B. We needed to respond quickly and adopted an Agile approach to our digital campaign strategy in order to have a skinny version of the website up and running as soon as possible. We used a mix of Scrum and Kanban methods to prioritize widgets we required on the website and ensure our campaign remained responsive to stakeholders and built iterative changes to the site in order to respond to stakeholders and the political debate.
This is my Agile Lightning talk outlining how a mix of Agile approaches, namely Kanban and Scrum were used as a management tool to coordinate the development of a new website for the campaign. I demonstrated how the adoption of Scrum allowed the team to iteratively build features based on weekly sprint cycles and ensured weekly collaboration and communication between product owner, designers and developers of the website.
The introduction of a Kanban board to the Scrum process helped to manage the backlog of work packages and help focus the team on the ranked priorities for the current sprint. This provided a process to manage Workflow and allowed the team to remain flexible and responsive to the changing environment and stakeholder needs when changes were required mid sprint.
Sprint Planning
Sprint Planning was done utilising the Elements of User Experience Framework (Strategy, Scope, Structure, Skeleton and Surface) in order to plan what needed to be produced , what activities were required and requirements we needed to consider.
Kanban Board
- Needed to prioritize features to ensure campaign remained responsive to stakeholder needs
- Visual tool to manage the backlog, focus team on the ranked priorities
- Process to manage workflow and remain flexible
- Used it to manage 3 projects within the same program “Scrum of Scrums” Board
What we Learned
My Favourite Board – Fin!
Today, the most popular way people prefer to make contact with organizations is online as customers embrace new digital channels. We needed to modernize our digital presence to take the conversation to the channels where those conversations are taking place. Utilising an Agile approach allowed us to increase site usability and responsiveness to consumer needs and adapt and modernise our systems.
What We Did
- Used Agile and User-Centered Design (UCD) tools to elicit requirements, prioritize and groom backlog
- Allowed team to collaboration and get buy-in from stakeholders
- UCD tools developed iteratively to help determine value to stakeholders
- Agile process allowed alignment of wants and needs to prioritize & provide most value
Approach
Our Scrum Process
- 2 weekly sprint cycles
- Continuous integration to build upon skinny solution to respond to evolving needs
- Collaboration between product owner, scrum master and team
- Needs changing so estimation of what could be done and definition of done important
- Prioritisation helped us weight “$$$ Cost” vs “Opportunity Cost”
I recently presented an overview of the project to my organisation and demonstrated how personas were developed and workshopped with key groups to determine the needs and wants of consumers. The personas were also used to develop user stories which formed the basis of the requirements and feature sets of the site. Card sorting was used to understand how consumers classified the information and what features were of value. A prototype was developed which was a “skinny” version of the site and was used to communicate functionality and desired look and feel of the site to the team and to validate the site with consumers.
Learning Outcome
- User-centered tools and techniques are effective way to improve collaboration and encourage communication with stakeholders and within the development and design team
- Using a multidisciplinary approach (Agile and User Centered Design) enables you to ensure that the website is useable, adaptive and meets the digital needs of the modern 21st century consumer
Why is your project taking place right now? And not last year, or next year? Are there also any other projects taking place now? Why? What is the challenge? This can be either a threat or opportunity that is the cause / reason for the project. What is the legacy the organization wants to leave behind?
These questions matter. A lot.
Being busy in a project can be overwhelming. Before you know it you are only focused on this Big Adventure. Of course, your project is worth your time and attention. And of course, it is an incredible story, this temporary awesomeness that you and your mates are doing right now.
But it is just exactly that. A temporary story. When you’re done, you’re done.
Your project is part of a larger context. Longer journeys. Larger stories. And these stories shape your project more than you know. It’s like Star Wars. You can watch just episode IV. And enjoy it. But it starts really making sense when you watch the entire series.
Your project is an episode in two stories.
The story of you. The individuals that are involved in the project. An individual has an ambition and a reputation. And he has a role in your Big Adventure.
And the story of the organization.
You can address the Story of You with the Map Of You.
The same principles can be applied to the Organizational Journey.
By exploring the relationship of the project and The Organizational Journey, you and your team create awareness around why you doing things. Awareness beyond the normal “build this” specification. A sense of why you are doing what you are doing. This will help the team to make decisions that fulfill the organizations desires and be more in tune with its context.
Draw an empty map which basically looks like a bow tie. Put “NOW” in the center and “PAST” and “FUTURE” on both sides. Ask the participants to write keywords that answer questions as formulated in the first paragraph of this post.
This exercise is related to The Story Of Your Quest – exercise.
Other Maps.
The Organizational Journey is part of a change/project management strategy focused on culture and using an “adventure travel” metaphor. For more maps and exercise, visit my list of Shrinkonian exercises.
Bas de Baar helps people find ways to enjoy the diversity of human interaction in their projects and organizations so that they can get out of their own way and achieve their goals. - The Organizational Journey. Mapping The Project Context. is a post from: Project Shrink.
David G. Wilson brings a quote from Consultant-News.com, suggesting that “more and more people seem to be coming to a realisation that it’s not so much that their problems are complex, but that their problem is complexity“.
I have had a number of goes at the issue of complexity in previous posts and I have to admit that over time my view of what complexity is and why it exists, has changed somewhat.
Let’s see if I can explain it in writing:
From a critical analysis perspective the interesting thing about ‘complexity’ is that in essence, in reality, it does not really exist. It is rather a virtual perception, subjectively created by some observers but not by others. I often hear people commenting how ‘in the past the world used to be simpler’. If you contrast the changing reality in the world over the past 500 years or so it is not difficult to see that what some call ‘increased complexity’ is really increased level of interaction, increased lines of communication, many more interfaces etc. Take for example the modern TV remote control. Today’s TV remote control can still perform the simple task of switching the TV on and off. It can also change channels and control the volume. It can also perform some tasks that were not available in the past. For insance you can now freeze the screen, view what’s on in other channels, insert sub-titles, etc.
So it is not that the world has become more complex, it is us who have changed as we now want to manage far many more interactions than our evolutionary capability is allowing us to do comfortably. And this is where Darwin’s theory kicks in. Those of us who feel more comfortable in managing the increased load will do better than those for whom this increased load is a point of increased pressure, tension and distress.
With the above in mind it is clear that reducing complexity will not be possible unless we change our nature and adopt a less competitive nature. Naturally, this is unlikely to happen and so we can expect complexity to further increase.
Think about it!
If you asked me to point a single thing, which I hate most in senior management role, I wouldn’t have any problems with the answer. It would be firing people. On my personal hate scale there’s firing, then huge, huge void and only then other unpleasant things and tasks to do.
Each time I fire someone I feel like a complete jerk. It doesn’t matter that the decision is well-grounded. It doesn’t even matter when I’m proven, after some time, it was the right choice. It isn’t any easier.
And the next time you do it doesn’t become any easier either. I mean if executing such decisions is easy for you and you feel comfortable firing people there must be something seriously wrong with you.
Yet I still think firing people is extremely important part of pretty much any management job. If you’re a senior manager you likely have power and authority to make such decisions. If you’re a team manager dealing just with your team of six or something and you don’t have that much of power, you still can convince your superior to make a tough move. Sometimes the latter is even worse as you have to do all the talking as it is you, who started the whole thing.
OK, why is it so important then? Because this is one of methods of building great teams. As harsh as it sounds: sometimes you don’t have enough resources (meaning: time, patience, money) to make a person act on acceptable level and the best thing you can do is to split your ways.
Don’t get me wrong, my advice still is: do everything you reasonably can to fix an underperformer. I know way too many people who started shining when given a second chance to say otherwise. But then remember that it’s a manager who is responsible for building the high-quality team, so if you just accept the underperformer in the team you basically harm the team on many different levels.
What more, sometimes we’re out of luck and we don’t have all the time and money of the world to try virtually every possible thing one could think of. Sometimes our fixing options would be limited. Sometimes constant resistance of the underperformer will make us lose faith faster. Shit happens. We don’t live in ideal world. And then it’s time…
Well, for many managers I know then it’s time just to accept the fact someone is underperforming. And you know what? I understand them. I understand them because firing people is so damn hard and so freaking unpleasant that I can think of thousands of reasons why I shouldn’t do that. At all. So yes, I can perfectly understand them.
But I don’t agree with them. We are paid to do our jobs even when the jobs suck on occasions. When we make our developers write boring documentation which just has to be done it works similarly. The only difference is in level of responsibility. But we still expect our developers would deal with crappy tasks, don’t we?
Having balls to fire people isn’t something which makes a manager. In fact, with a bit of luck we won’t need to fire anyone for years and will be able play the role of guru manager neatly. However, when time comes you better be ready to deal with the worst management task ever. Otherwise your whole team will be constantly taking big hits on morale and you no longer will be considered a rock star manager.
If you’ve just lived through such situation for the first time I have two messages for you. First, it’s one of the most valuable experiences as a manager you can possibly have so good for you. Second, yes, I know how crappy you feel now and it’s not going to become easier next time you do this, sorry.
The discussion of how do you know what done looks like? in the agile software development world has many answers. Ranging from we'll let the customer tell us, to we have this collection of User Stories and Use Cases that tell use what done looks like.
Jens Coldweys (turn on translation) blog speaks to the use of Use Cases and Scenarios in the development of software. These Use Cases and Scenarios need a Reason for existing. This reason is usually missing or is linked to the wrong source.
- The reason we need this is the customer says we do
- The reason we need this is that any system like this has this requirement
The missing piece is not only why but the connections between the why and the actual mission outcome. By that a business mission, a government mission, a military mission, any mission.
So before the next step, let's put some definition out there:
- Mission - why we exist, why we want this system.
- Values - the guiding principles we'll use in fulfilling the mission
- Vision - the picture of the future
- Strategy - the differentiating activities that will be used to fulfill the mission
So where do these Use Cases and Scenarios come from? Good question. No answer to that question? Then these Use Cases and Scenarios have no real reason for being other than someone or some group says they want it. But that usually leads to trouble when those needs and wants themselves don't have an architecture.
- How do they relate to each other?
- What are the dependencies between them?
- Which are more important than others? This is not a ranking system, but which are more important in terms of fulfilling the mission?
The answers to these questions come from the Capabilities Based Plan for the project. This Plan states what capabilities are needed for the mission to be successful, for the system to provide the needed outcomes for the customer, for any result to fulfill its mission.
Don't know what capabilties are needed, the units of measure for those capabilities? Then any set of Use Cases or Scenarios that the user and developers come will likley be OK. This is the same problem with the requirements elicitation process. Requirements need a reason for being. A Raison d'être. Why do we have this requirement, why do we have the Scenario.
Here's how to develop those capabilities statements. Without answering these questions, those wonderful scenarios, Use Cased, User Stories have no real reason for being in the context of a "system."
In 1935, Bill Wilson – an alcoholic whose doctor had given him 6 months to live if he didn’t quit drinking – had a vision. His vision was that while experts were ineffective in curing alcoholism, the addicts themselves were the keys to helping one another overcome the disease. And with that, Alcoholics Anonymous was born. Today, they help over 2 million members and have been the model for numerous Anonymous addiction recovery groups.
In the 1980’s, Richard Stallman’s fierce beliefs in freedom and in the importance of free software (free as in free speech) towards securing the future of a free society led him to create the Free Software Foundation. FSF became the impetus behind the open source movement. Today, developers around the world freely volunteer their time to develop the open source software that tens of millions of us use every day.
In 2000, Jimmy Wales decided to launch a free online encyclopedia for children whose parents couldn’t afford their own. After a tedious process that produced a mere 24 articles, the encyclopedia’s editor – Larry Sanger – introduced wiki technology. That decision led to the 100% user generated encyclopedia that ultimately cost Larry his job. Today, Wikipedia is the world’s largest reference site with over 3.7 million articles. It attracts over 400 million unique visitors every month.
The Community
What is amazing in all of these instances is how people stood up and contributed. Contributed even though there was no clear reward for them to do so. AA members took the 12 Steps and created new chapters around the world, running those chapters with no involvement from Bill W. Developers regularly volunteer their time to create hundreds of thousands of open source projects. Wikipedia’s users not only write the articles, but they serve as custodians to the site. Ask Jimmy Wales who runs Wikipedia’s servers and he’ll tell you he has no idea. The users decide for themselves.
Not only do people voluntarily contribute, but they contribute high quality. A research study found Wikipedia on par with Encyclopedia Britannica for accuracy. And much open source software is considered the best of it’s kind.
The Catalysts
Bill Wilson, Richard Stallman, and Jimmy Wales are all catalysts. Catalysts are visionaries that develop amazing ideas. But instead of holding onto those ideas for themselves, they share their ideas with others. And they inspire others to take action on them. And then, the Catalyst steps out of the way and lets the community carry the idea to incredible results.
Catalysts share their ideas, but they don’t take ownership. If they had, every new AA chapter would have had to go through Bill W. and it would likely have never have reached as many it did. When Jimmy Wale’s initial free encyclopedia was “owned” by him and his editorial team, it managed 24 (as opposed to Wikipedia’s 3.7 million un-owned) articles. And Richard Stallman is quite vocal about his dissatisfaction on open source’s split from his initial vision. But he doesn’t take them down, and so the open source movement continues to grow.
Unstoppable
By not taking ownership, catalysts allow each and every member of the community to take hold of that ownership. The power is distributed to all of the people and these communities become unstoppable as Ori Brafman and Rod Beckstrom describe in The Starfish and the Spider: The Unstoppable Power of Leaderless Organizations.
The catalyst’s presence almost always remains felt, but catalysts understand it’s all about letting go and trusting the community, because that is where the true beauty lies.
“When you give people freedom, you get chaos, but you also get incredible creativity.”
Trust is a beautiful thing.
http://ignitemelbourne.eventer.com/talks/1001
