Project management consultant, human being.
Neither teenager(s) or Agile projects do well under helicopter style management, but the parent, or PM's urge to operate this way is very hard to resist. It's tough when you find that your customary approach to feeling in control of a situation no longer works and it's very hard to resist worrying all the time, about whether you should be worried or not, especially when the subject of your worry is adamant that its "all good".
In a plan-driven software development project, the number of requirements completed versus the planned requirements completed over time appears to provide meaningful information about a projects status, any deviation from the plan is seen as a red flag. When there are a lot of these, you know exactly when to worry. In the context of an Agile project, things are not so clear cut, the team may be delivering done requirements on a regular basis, but the extent to which these represent business value is the key indicator. There are obviously challenges in quantifying something as subjective as business value, but this represents the only the tip of this particular iceberg. Both Agile approaches and plan driven approaches have the same goal, which is to improve the outcomes of the software development process but they approach this goal from fundamentally different philosophical perspectives. This philosophical divide becomes very evident when an organisation tries to introduce Agile methods at the team level, but fails to do so at the project governance level.
When I needed to select a research topic as part of my ongoing studies, I decided that it would be interesting and possibly useful to investigate this. I was particularly interested in finding out how this issue is solved by organisations who's governance and reporting infrastructure is designed to use data from plan driven projects, but which develop software using Agile approaches. This research will take several months to complete and as always step one is a search and review of the academic literature in order to understand current thinking and knowledge.
Whilst there is a lot of fantastic and relevant material in the professional literature (everything which doesn't count for the purposes of ERA) my review includes only the academic literature which presents empirical research and has been published by ERA ranked journals and conferences. Doing this review was an interesting exercise I learned a great deal but the output does not constitute light reading, so for fun, I've winnowed 12 years of literature and the 6000 words I wrote down into 3 paragraphs.
I found that between 2002 and 2006, a lot of research was conducted which looked at Agile transitions in general, while there was some discussion of project governance and reporting most focused on the implementation of Agile methods and the experiences of those at the team level. Where governance and reporting was covered it was identified as an emergent problem. Between 2006 and 2008, a number of case studies were published which did focus on this issue, my personal favourite being a detailed study of the Agile transformation undertaken by an American energy company DTE Energy where the introduction of Agile methods and the focus on delivering business value at the project level is credited with being a key factor in the organisations achievement of CMMI accreditation.
Post 2008 the topic seems to vanish from the academic literature, there are a few papers which discuss very specific ideas such as using earned value analysis (EVA) to report on Agile projects. There are also a number of studies which report on organisations where a move to an Agile approach was undertaken at the whole enterprise level and where working with stage-gate governance approaches is simply not a factor. In some cases Agile methodologies were seen as the only way to manage the complexity and variability of a specific project, in other cases, such as at Cisco Systems, the use of Agile approaches as best practice was taken so seriously that the organisation invested in an Agile office as an adjunct to the Project Management Office (PMO) in order to ensure that everyone was on the same page. I suspect organisations which take this kind of approach are unusual and that 3 or 4 years ago it was still the case that the adoption of Agile methods was most often driven by software development practitioners rather than from the C suite.
Whilst the academic literature didn't provide any clear answers, of the 20 - 30 papers I reviewed a number of strong consistencies did emerge and included the following, all of which, I think most practitioners would consider to be in the "duh" category
- Stage-gate approaches to project governance are potentially very compatible with Agile methods.
- The key success factor for organisations considering Agile implementations is the incorporation of Agile values across the enterprise including at the leadership level.
- The key failure factor for organisations considering Agile implementation is an inability or unwillingness to engage with Agile values at the leadership level.
- All Agile adoptions, are in fact Agile adaptations there is no "one right way" and that a pattern based approach rather than a prescriptive rule set is needed.
- That Agile coaching is almost more necessary at the C level than at the software team level, since software teams don't seem to have any difficulties seeing the benefits.
From a practitioner perspective things seem to have changed a bit over the last year or so; entering Agile as a keyword in a job search returns as many results for project manager roles and business analyst roles as it does developer roles. A quick search of the professional literature suggests that within the project and program management community reporting on your Agile project and the challenges this presents has been a key topic for quite some time now, but is still been driven by practitioner community. This looks a lot like the early majority, perhaps the C'suite will be the late majority, hopefully not the laggards.
At the very least figuring out what is going on here, will very likely keep me out of trouble and distract me from worrying about my teenagers for the rest of the year.
If anyone would like the full list of refereed papers and articles, please let me know and I will be happy to provide it.
So we all know the international Lean Kanban conferences are awesome and you probably know by now we're planning a Lean Kanban Australia/New Zealand conference 12-13th September this year. (Follow @LKANZconf if you missed it!)
The more interesting story is in our approach to validating the idea in a lean way. We're giving crowd funding a try and we're hoping this allows us to judge interest from the community, from sponsors and from speakers over a short 30 day test cycle.
So far we've picked the dates, started contacting speakers, researching venues, created a logo and setup our twitter feed.
Help us test our ideas: Visit http://www.pozible.com/lkanz and pledge to buy a discounted ticket or choose a reward that suits you. There are only 40 discount tickets available so get in fast to secure a really cheap price for the conference, and to show your support.
Also, talk to your company about the opportunity to sponsor the conference, they can sponsor direct from the pozible campaign or contact any of the organisers.
Finally, please put the word out via twitter or your own blog. Help us bring the world's best Lean and Kanban speakers to Australia. Let me know if you have any questions!
I use a trick with co-workers when we’re trying to decide where to eat for lunch and no one has any ideas. I recommend McDonald’s.This. Most definitely this.
An interesting thing happens. Everyone unanimously agrees that we can’t possibly go to McDonald’s, and better lunch suggestions emerge. Magic!
Next time a stakeholder won't give you an answer, consider giving them one. Make it a bad one. So stinky it almost runs them out of the room. Watch them trip over themselves to try and give you the answer you wanted in the first place. Love it.
So just what does a transition to Agile look like? I have recently read a a number of academic papers, journals and books on this subject (consequent to an ongoing PhD). As a result, I have learned a lot about the underlying theories and philosophies of Agile software development (including numerous accounts of Agile transitions); many of which have been the subject of rigorous empirical research. I have also learned, that there are any number of freely available lists, taxonomies and frameworks; many composed by well known authors, thought leaders and industry experts.
However, I have not yet come across one which describes anything quite like the day to day experience I have been living for the last 6 months: co-leading a team of IT professionals from working in a world which was definitely not Agile to somewhere that is now describable as Agile.
Most of the empirical research I have read has been of great value; I believe that bringing an understanding of theory to your practice is vital: it helps you to become a better practitioner. But none of the beautifully written theories or frameworks describe the world that I live in right now. Practical advice for day to day survival in an imperfect world seems thin on the ground.
The thing that has helped me survive (so far) the feeling of imminent drowning in items to address, has been what I learned from a website all about housework. The rest of this post is a light-hearted attempt to draw a comparison between transitioning to Agile, and the process of getting your house in order as described on www.Flylady.net.
I found Flylady a while ago; I was engaged in a domestic engineering project involving two babies and a part time undergraduate degree. I stumbled across the website and saw myself described on the homepage. I was suffering from C.H.A.O.S (can't have anyone over syndrome). If anyone ever did want to come over and visit, I would do just about anything to avoid it; I did not want anyone to see the unmade beds, scattered toys, fingerprints and laundry (Mt Washmore rivaling Mt Rushmore) to be done.
The Flylady website was offering a cure for free, so I accepted. I found lots of useful materials on the site, especially for those who really do want to become a domestic god(dess). Generally the website message is light and positive. Some folks might consider it all a bit cheesy; Flylady stands for "Finally Loving Yourself" however, if you can work through, or skim over this, it delivers some key messages and ideas which could apply to any complex endeavour. I'd like to reference some of this material and the way that I have found it useful in my current context.
1. Don't try to catch up, jump in right where you are
It would be nice to have things all planned out, it would also be nice to have the time and resources to implement a textbook Agile transition, with an appropriate project, training, management support and enthusiasm all in place first. Does this ever happen?
If there isn't the will, the time or the resources, you just have to start somewhere. You can't drive yourself crazy trying to convert all the use case documents to user stories before you begin. It's ok to just start from the next sprint, it's also ok to try a process or approach, learn from it and change it. We started with stand ups and began to grow into our transition from there.
2. Daily habits one new habit a week
Flylady starts with asking you to add one simple practice to your life each week. The first idea is that you shine your kitchen sink every night (this implies doing the dishes), so that when you wake up in the morning, it looks good and makes you smile (this one works!). Also, the contention is offered, that if the kitchen in a house looks tidy the rest of it also looks better.
Practices are added each week throughout the year and if you follow all the advice on the habit list I'm quite sure that you would end up a domestic paragon. I never managed this, but mostly still adhere to shining my sink, getting dressed to shoes and prepping my clothes for tomorrow every day. Having one day a week for school and family paperwork, and planning the menus for the week are also valuable Flylady habits. I have not achieved a self organising team to do the cooking though.
We have added one new scrum practice every week or so, we refine them as we use them. Most recently we started to really emphasise the importance of each team member understanding wider priorities and selecting work based on these. We are making good use of our retrospectives to prioritise practices to review, but it still tends to be on a firefighting basis.
Divide your home, or your endeavour into zones, my house has rooms, my project has areas, such as requirements, development, QA, Dev-ops and process improvement. Focus on each of these in a rotating cycle, and "De-clutter" (clean up) in the current zone for 15 minutes a day. The kicker that goes with this advice, is that "you can do anything for 15 minutes" (set a timer).
You can get through quite a few of those old use cases in 15 minutes a day every day.
I could draw many more detailed examples, but I think that's probably quite enough for a blog post. Especially one which includes housework. I will be spending the remainder of this year working on a research project which will try to understand and describe what Agile transitions are really like, I hope to propose some practical solutions for others to use. Consequently, my house is total chaos again. This time, I don't really mind, my babies are now teens and we all love having people over.
"The inspection foreman a god job of breaking in those girls..."
Let's keep challenging bad practices and assumptions.
Things that went well;
- I learned how to uncover the size of a hidden technical backlog and plan sprints around it.
- I learned how to share knowledge, quickly and without lecturing
- I learned how deliver less than desirable news
- I got to meet and work with a number of interesting and deeply intelligent human beings
- I learned how to set up and administer Jira and Greenhopper like a boss
- I delivered what I said I would deliver, when I said I would deliver it
- I didn't hide and I took responsibility for my actions when I got it wrong
- I submitted all my study assignments and scored respectably for them
- I didn't neglect my family quite as much as I could have
- I discovered my family are more self-sufficient than I thought
- Do better due diligence ALWAYS
- Correct, detailed requirements are really really important, but the details about how they are shared and recorded is not.
- Leadership is not given it is always taken, but “followship” must be given freely
- Yes assumptions do make an “Ass out of U and Me”
- I learned SO MUCH, I discovered that I am capable of doing so much more than I thought I could
- I handled situations I had never come across before (because I had to)
- I reaffirmed for myself, what I really want to do and more importantly, what I do not want to do
- I care about doing what I do well, not just the technical practical side of being a BA or a PO but both; I think/know that I can be a better BA if I use Agile methodologies. Either, by itself is not enough and never will be
- I want to make beautiful, usable software, but in the best possible way.
- I want to really;
- understand how this can best be done; and
- teach others how to do it
- Transfer from my current professional doctorate to a PhD
- Find a job which pays the bills, but doesn't follow me on holiday
- Write the darn PhD
- Find a nice university where I can research this stuff, write about it, talk about it and teach it; without starving in the process
- Finish seeing my kids through high school first
The basic set-up
- There is an initial set-up round per the original rule set
- I then work in 5-8 minute rounds
- At the end of each round I call out an event from a deck of event cards I made up
- The team need to respond to the event cards in the following iteration
- The event cards can be given to the teams and they can play them at heir own rate if you want to let go of control
What can you learn?
- Is it easier for one person to design an organisation or to do it as a group?
- Is it better to manage a set of Self-organising, cross-functional teams or to manage specialists groups? What about hybrids; where do they fit in?
- What does organisation design do to system architecture?
- How does an uncertain environment help or hinder organisational agility?
- How should teams and customers organise their relationships?
- What is an optimal team size? How do you manage growing pains for teams?
- You can download the game here; http://www.management30.com/product/meddlers/
- I’ll be facilitating this game at Scrum Australia in April. Come along of you are there.
- You can also arrange to run this game in house, either stand-alone or as part of the Management 3.0 training course. Get in touch via Tabar.
I regularly ask people at the end of meetings, discussions, etc "Was that valuable for you? Why or How?"
Constant incremental feedback helps tune the way you work.
With that in mind I am thinking about polling my stakeholders regularly with a simple survey. As a read of this blog you are one of my stakeholders.
Feel free to give me feedback via this survey form at any time.
If you have suggestions for me about this idea, they are also welcome.
It is going to be called Tabar. It is a place for agile practitioners to come together and share.
We are going to do that whole modern agile business thing where it's a membership model. In principle the organisation will be owned by the team. Revenues will flow back. It's not certain how some of the details will play out, but the key thing is that the organisation is a community, and that it's main goal is to provide value to the community members.
Ben put it nicely when he said the value proposition is in people being connected to each other.
We have looked to Crisp and Happy Melly as examples. Our secret ambition is to have more people tell stories about our venture than these other teams. (Oops, not so secret now.) But really we look to these and similar companies as parts of a broader family more than competition. The future of work lies in collaboration.
Why the (brackets) around the word? Because we don't want to be 'just' agile. We have a range of skills and insights tat we can bring. Agile is big in the market right now, and that community is how we know each other, but we also consider the agile toolkit broad, but not sufficient for all circumstances. (For example, is Kanban without Scrum/XP agile?)
There is a much more comprehensive and coherent statement of what this is about, but you need to have it face to face. Next time you see me, come and grab me or one of the other team members and we can explain it to you if you are interested.
We'll also declare this at upcoming community events, including Scrum Australia which is coming up in 2 weeks.
This is the sort of question that can't be easily answered in a public discussion because there are so many interpretations and assumptions embedded in the question. Let's unpack.
What is Scrum?
Scrum has been around since the early 1990s. It arose from software development teams.
It's a framework for doing things better, with a strong orientation to building software. Scrum's authors are Ken Schwaber and Jeff Sutherland, and there are two organisations, Scrum.org and Scrum Alliance that provide some sort of governance over the Scrum community, providing tracing, certification and publishing rules and guidelines.
What is a Product Owner?
Your product owner readies and orders the backlog for the team. To do this they reach forward in the value stream, out to markets, customers and other stakeholders to make sure the team is building the right thing.
You can read more on this from some of the official sources above. To start, there is the Scrum guide from Scrum.org, and the Scrum Alliance has it's Core Scrum summary. I find this extract from the Scrum Guide particularly useful.
- The Product Owner may do the above (typical list of P.O. activities) work, or have the Development Team do it. However, the Product Owner remains accountable.
- The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a backlog item’s priority must convince the Product Owner.
- For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No-one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.
Ken Schwaber elaborates on his blog in a number of posts on Product Owners. Schwaber is quite elegant and simple in his description. Some points I take away from his writing are;
- Product Owners are a great tool to help organisations understand the value Scrum teams adaptability and flexibility can bring.
- Product Owners come with the power to make decisions; it's not about story writing. It's about finding where value lies.
- General and Product management and Software-Scrum teams still don't typically understand each other and the Product Onwer, with the Scrum master helps bridge the two tribes.
- Is it still Scrum if you don't do daily scrums?
- Is it still Scrum if you don't have retrospectives each sprint?
- Is it still Scrum if you are pulling a PBI from your backlog directly after finishing the previous one, rather than in iterations?
"In short, you should be asking "Will I be more likely to succeed if I don't have a Product Owner?" or "Will design iterations improve my chances of success?", not whether you'll still be doing Scrum or XP or YourBrandHere if you do those things."Ron's article expands on the idea of learning from the experience of others. Take the time to not just master, but to understand the practices and reasons why the work.
You'll hear me talking about dropping Scrum practices in one context or another. Sometimes it is because the organisation doesn't want to deal with Scrum. Sometimes it is because I am working at a different level to team delivery. Sometimes it is because the team is using XP or some other variation. Rarely, but sometimes, it's because a team is able to be more effective by moving past the fundamental practices.
I have had my best agile experiences working in and with Scrum teams that do it by the book (often also pulling a lot of XP along as well.) I have to say I'd trust these guys. It's not two crazy people with an idea that just might work. It's a community of thousands with decades of experimentation and observation under their belt.
So, here we are at the end of the blog post.
Do you have the answer yet?
No, there is no Scrum without a Product Owner.
Yes, you can be effective without Scrum.
Learn the basics by being successful with them before you challenge them.
Product Owners are powerful and important roles in Agile frameworks.
We should explore this, but if we do, we won't be doing Scrum.
You probably know the Five Whys. Challenge the assumptions by drilling in with more "Why?" questions. you might sound like a four year old but you'll push past superficial reasoning.
Can we level up this technique?
This Simon Sinek video is also pretty well known. "People don't buy what you do, the buy why you do it." It explains a rationale about how our rational brain connects with the what, but our emotions connect with the why.
It's 5 minutes and quite compelling. Check it out.
Ask yourself what do the people you are interviewing want to talk about. (See what I did there?)
And then you can ask how best to engage with them. (See that again?)
Once you have worked your way through this you'll be able to work you way up the question hierarchy Sinek talks about.
At this stage I get to check whether you watched the video. Did you hear how he said leaders think about the shy first? Research and discovery work needs you to engage with anyone, and so you sometimes need to start somewhere else.
So here are some "What questions to help you on your way;
- What is it we are doing here?
- What circumstances led to this?
- What if we stopped doing this?
- What does the customer think about this?
- What would mean we can move on from this?
I saw this article on UX strategy and Agile: Is UX Strategy fundamentally incompatible with Agile or Lean UX.
It's a reasonably well put together article, but I'll save you the trouble. Apparently they aren't compatible.
I value UX. I worry about knowledge management and how hard it is in large organisations and communities. UX is a form of knowledge management. I struggle with agile in the enterprise. Agile is hard and enterprises like short-cuts. I think about these things and I try out experiments all the time. I want a better world.
Maybe I am in a grumpy mood, but it irks me when people put up a straw man and then argue their case. It's a cheap debating tactic and I didn't like it when agile folks did it to project management and I don't like it when other practices do it here.
Let me unpack the argument a little more succinctly for you;
If you are sloppy with your work and you fail to think about the whole picture you will end up doing a shitty job.
Here is a picture comparing UX (strategy) and Agile and highlighting its issues of compatibility.
Let's work together people. Stop trying to be the cleverest kid in the room.
Both companies are explaining their change in approach in the context of a call to arms to re-engage the workforce in transforming the business. There are lots of quotes about collaboration and the creativity and energy that comes from working with your team.
And it's probably fair enough. And it's true that changing times call for new ways of doing things.
But why didn't these idealistic approaches accommodate the change these companies needed?
I suspect that it has to do with commitment.
We commit to people. We are loyal to people. When we don't mix with people in a social setting we lose our place in the community, and a feedback system spins up where loyalty atrophies.
So an alternative to abandoning ROWE and WFH would have been to build better online collaboration spaces. I imagine that would have been a superior approach for Yahoo! as it could have helped them spin up new business propositions.
Answer these questions for each of your projects? How do you feel about the answers? What will you do?
- Do we have a defined goal for the program?
- Is there any objective measure of success or failure?
- Does each program have a goal and measure of success/failure?
- Do we have a portfolio sponsor?
- Does each Program have an owner/sponsor?
- (are we all using the same language around sponsor and owner)
- Does each program have a governance structure? eg steering committee and working group? Product owner?
- Do programs require funding?
- Is the program funded?
- If not, is the sponsor championing the funding? Is it at risk?
- Does the funding cover all costs?
- What about operations costs?
- Are there any hard deadlines?
- Are there any cross project dependencies?
- What is the value we can add to each program?
- Have we discussed and agreed our contribution and role with the program?
- Do we have an appropriate solution pathway?
- Is there is a reliable system for delivery? Will anything get in it’s way?
- What environmental and situational risks affect the programs?
- What/how does a blocker get cleared for these teams?
Lots of people on a conference and nobody interacting. As the facilitator you want people to participate and you know that there is lots of good insight and opportunity in the group, but you struggle to pull it out into the collaborative space.
A simple technique
Break people up into small groups who collaborate on Communicator in the background. Have them share back to the main group (maybe via a spokesperson) in the main phone conference.
Our team has tried this a few times now and each time the feedback from participants is that it works well (compared to the way things were.) From our perspective it also yields good useable insights that we can take away from the meeting and inject into our program.
We spent several minutes briefing people in on the objectives of the session and the approach, emphasising that it was an experiment. We assume this positioning helped open people up to exploring and trying the technique with an open mind. We also broke people into groups of 3 with no particular social engineering agenda at play, but happy with the diversity in teams that our randomness generated.
We got each small team to fire up a Communicate group with their two team mates and confirm on the phone that they were ‘live.’
We then briefed them on the goal and approach again – there will be a 5 minute iteration (we could have run multiple iterations for more complex problems) and then a spokes person will share back the key points of the discussion.
The phone bridge then went onto mute while the teams worked. I opened up the phones again a minute before the end of the working time and called in the last 60, 30, 10 seconds.
We then went around each group and collected key points and discussed across the group. At this stage most people in the meeting were sufficiently engaged and warmed up to participate. (This example had about 22 people all up.)
We captured the key messages and ideas and collated them in a MS Word doc which we distributed after the meeting. An improvement on this aspect could be to use Google Docs as your collaborative document tool as you go in the room.
Some constraints we considered when designing this activity
We decided when planning this activity for the first time that we should stick with tools that everyone uses day to day, so no web-ex or other internet tools, no fancy multi-space chat rooms or any of that. Just keep it simple by sticking with tools that were on everyone’s desktop.
Some feedback we have had
Overall it works and is an improvement on the normal leaders tell/passive audience teleconference meeting form. Short cycles works because it keeps people focused. Also longer cycles would be better because it allows more time to get to know each other when you haven’t worked closely before.
Why this works
Large groups don’t feel like a place you can open up in. Phone conferences add another dimension to this as you don’t know who is on the line. People don’t feel safe speaking out and prefer to stay in the status quo of “passive audience member.”
By breaking the large group up into smaller groups people can more easily interact as individuals and make a fuller contribution. The further away the interaction method is from face to face the smaller you need to make the groups. But don't go below 3 otherwise you lose some of the magic of collaboration.
If you live in Sydney and want 2 days of Scrum conversations with your peers out there in the agile community check out Scrum Australia's April conference.
Jump in early to take advantage of the very significant early bird discounts.
I'll be running Jurgen Appello's Meddlers game (which is a load of fun) on the morning of day 1, so drop in and say hi - and stay and play the game with me.
The whole program is published at the Scrum Australia website. So are Ed Wong and Anton Rossouw. Frank and Herry will be reprising their talk on offshore scrum teams. And newcomer to Australia Berndt Schiffer will be making his first Australian conference presentation. Lastly Martin Kearns from SMS will be closing with a keynote.
So it will be just like being in Melbourne :) Only warmer.
Here is the scenario I ran through last night;
I finished reading a book on Kindle on my tablet and decided I wanted to buy the sequel. I went to the Kindle Store in the Kindle app and was transported to the browser (1).
I then searched for the book and found it. Strangely the price was in pounds (2). Whatever; I click through with the intention of buying. But wait. I can't buy on what turns out to be amazon.co.uk because I am in Australia (3).
So I have to click through to Amazon and hey, I have to begin the search for the book again (4).
Lucky the have a patent on one click purchases (5) as I was about to give up.
Then I buy the book, but it doesn't ship to the tablet I am on (6). I go back and see the default destination is to my other older tablet (7). So I resend it to my new tablet (8) and it starts to deliver.
Overall it is a pretty poor user experience and one I suspect that comes from incremental additions to the feature set. Agile development everywhere is at risk of delivering poor user experiences like this.
This is akin to technical debt, but it is more apparent to customers. I suppose you could call it UX design debt. Pay attention to it because it sucks and drives business away.
Let's run through a few of the failures and what might be a better approach:
- Browser navigation of Amazon sucks on a tablet. The page doesn't present for a tablet experience or the screen size. And why the hell are you taking me out of my nice cuddly Kindle space into a jarring other place anyway?
- Shouldn't the browser know what country I am in and deal in my local currency? And you have my account details as well so you know what country I come from.
- Why the hell doesn't the website just ignore what country I am in and deal with the regulations around regions under the hood? Why doesn't Amazon just operate as a global platform and customise locally once we get into a transaction, rather than before?
- Why can't you carry my search and landing page forward as we change domains?
- Seriously Jeff, patenting One Click purchases sucks. Why would you do that?
- You know I initiated a search on the back of reading the prequel on this device. I am buying the book on this device. Why would you think to ship the book to any other device?
- Especially one I haven't logged into - or even turned on - in over 6 months?
- Selecting devices on the browser is another fiddly and non-obvious activity. Oh, and the pull down feature in Kindle isn't very obvious to a novice user either.
RT @LASTconf: Heads up. We should be releasing the first wave of registrations for #LASTconf, next week.
Hey coders, are any of you heading to http://t.co/ncRlr2QuRA? What do people think about a competition looking for the best coders?
@kb2bkb has inspired the next agile movement. BACON - build a culture, oppress nothing. Things always go better with BACON.
The #ValidationBoard just launched! FREE tool to test startup ideas without wasting time or money. http://t.co/Pzjj9vGRWQ via @Lean
@RKarnali see you there
@Erdbeervogel and 30
@Erdbeervogel flexible but we like short and sharp
@Seilevel it's funny you trolled them. I would have just trawled.
RT @MrAlanCooper PLEASE GIVE ME A DECENT CALENDAR PROGRAM! PLEEEEEEUUHZ!
RT @paulculmsee A psychologist keynoting a #SharePoint conference? I am sure it makes sense to some :-) http://t.co/cJERGI4QiL
RT @kelseyvh: There is a very fine line between enjoying a challenge and being weirdly masochistic. The key is knowing when you are about t…
If you're an independent consultant looking to join a larger network you might like to get in touch. (Melbourne)
Help! They're running an Agile project, how do I know when to worry? http://t.co/0i54p7U62J #pmot #baot
@agileboardhacks looking forward to yours Nick
@carolineggordon closest Sydney thing is Scrum Australia.
@RonJeffries @PapaChrisMatts @LeanVoices @AdamYuret @estherderby @cyetain Start with using the hash #NoProcess :)
Presentation by John Giles to Melbourne Scrum User group. From 26 Sept 2012
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!
I gave this talk at PMOZ last week.
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.
A little information on writing good user stories
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
Melbourne Agile and Scrum User Group
Are you doing Scrum right?
Tonight we break down scrum and check ourselves against the Scrum checklist that Henrik Kniberg originally put together back in 2008 but evolved over the years.
It would be a good opportunity to bring your whole team, as you can work together on responding to the issues that come up in the conversation.
The format: Small groups, facilitated discussions and sharing back to the man group in several short iterations.
The learning outcome: You know specifically what you are or are not doing in the context of the Scrum framework.
Bring: Post-it notes or index cards, because you are going to walk out of this with actions to take back to work.
Melbourne - Australia
Wednesday, May 29 at 6:00 PM
Melbourne Agile and Scrum User Group
The first nation-wide hacking event, with over $50K in prizes (let's make sure Melburnians win the lions share!). Further details here:
Melbourne - Australia
Friday, May 31 at 6:00 PM
Melbourne Agile and Scrum User Group
Walk through a guide I created to help people with preparing and facilitating retrospectives followed by trying out a few retrospective styles as a small group exercise
Melbourne - Australia
Wednesday, June 26 at 6:00 PM
Melbourne Agile and Scrum User Group
TBC. Suggest a topic
Melbourne - Australia
Wednesday, July 31 at 6:00 PM
Melbourne Agile and Scrum User Group
Come and meet the Melbourne Agile tools teams.
The goal of this session is to provide you with exposure to some of the leading Agile tools in the Melbourne marketplace.
We'll have each Agile tool vendor set up with a stall. We will break everyone up into small groups and then run a series of iterations.
Each iteration people can switch to a new tool vendor conversation or continue with the one they are talking to.
If you'd like to participate as a presenter please get in touch.
Melbourne - Australia
Wednesday, August 28 at 6:00 PM
Melbourne Agile and Scrum User Group
Melbourne - Australia
Wednesday, September 25 at 6:00 PM
Melbourne Agile and Scrum User Group
Melbourne - Australia
Wednesday, October 30 at 6:00 PM
Melbourne Agile and Scrum User Group
TBC. Suggest a topic
Melbourne - Australia
Wednesday, November 27 at 6:00 PM
Melbourne Agile and Scrum User Group
We have two great topics tonight. We'll run them concurrently.
Agile and Mainframes, with Max Roy
Coaching conversations, with Stephanie BySouth
Join Max Roy for a presentation into using Agile methods in Mainframe environments.
Although Mainframes are traditionally associated with Waterfall projects, this presentation aims to show that Agile projects can happen on legacy mainframe applications.
Max will discuss
- How to do Agile projects on mainframe platforms
- Share certain war-stories on Waterfall projects and why Agile is superior
- Remove certain miconceptions about mainframes
Max's career spans 25 years in roles such as Solution /Data /Application Architect, Project Manager, Business Analyst and IT Faculty/Trainer. He has an innovative yet pragmatic approach and end-to-end delivery focus in all phases of the SDLC, using a wide array of agile techniques into both planning and execution.
His current focus is on implementing hybrid Agile methods on mission-critical projects with a focus on delivering business value.
Join Stephanie BySouth on an investigation into how to be a better coach. In this session we will be looking at effective coaching techniques. This will be a facilitated workshop style event.
Melbourne - Australia
Wednesday, December 18 at 6:00 PM
Agile Business Analysts, Melbourne
Dear Analysts (aka hackers!) we would like to invite you to attend (and/or compete) in the upcoming nationwide GovHack event (the first of its kind in Australia!). The Age newspaper in collaboration with the University of Melbourne have sponsored the event and are hosting it at the fabulous Media House (next to SouthernX station).
We'll have over $50K worth of prizes on offer (ranging from $500 to $5,000), including the Melbourne 'Beautiful Data' prize:
We would love to see your community come along to enjoy this free event, as well as win some of the prizes (hopefully more than the other seven Australian cities competing #friendlyrivalry #melbournerules ;-)
The event launches Friday evening at 6pm, with lots of fun networking activities (have you ever experienced balloon bingo?!), and of course the announcing of all the prizes on offer
If you do want to compete we'll have hacking space open all day on Saturday and Sunday at MediaHouse (June 1 & 2). Contestants will need to submit a three minute video by Sunday evening to enter the competition. Last year 1/3 of the team that entered won a prize, let alone all the networking opportunities to build your community.
In short, we really hope you will come along and bring your fellow hackers!
Tickets are going very quickly so please do get people to book ASAP:
Greatly appreciated for any considerations. Please don't hesitate to email or tweet me if you have any questions: firstname.lastname@example.org (Australian National Data Service). @DFFlanders
Hope to see you there :)
Melbourne - Australia
Friday, May 31 at 6:00 PM
Agile Business Analysts, Melbourne
Join Agile coach Stephanie Bysouth in a conversation about Agile Coaching.
What is it? Why does it help? What are some techniques can that work for you?
Melbourne - Australia
Tuesday, June 11 at 6:00 PM
Agile Business Analysts, Melbourne
This will not be a regular format meetup - don't come along to this one and expect to sit and listen to a presentation. I want you to be involved in this topic.
We all do documentation of some sort, (you do, don't you?) and it is boring, time consuming, never gets updated and no one ever reads it.
But I'm sure you have some great examples of documentation you have done - so bring it along to share* - this meetup is going to be part show-and-tell and part discussion.
Every time I do documentation, I think I'm reinventing the wheel and working alone most of the time, I don't get to see how other people do things really well, so it would be great if we can showcase some of the examples of great documentation that has really helped your team, your clients, or your workplace in some way.
As well as the show-and-tell, I would like to lead a discussion about documentation, what it is, why we need it, what types of documentation are there, and how can we make it easier to create and easier to update.
If you think this topic sounds boring, then it is the perfect meetup for you to come along to, and hopefully you will find it a bit less boring and tedious next time you *have* to do documentation.
* Please ensure your documentation examples can be shared with the group or has all your work's confidential details removed.
Melbourne - Australia
Tuesday, July 9 at 6:00 PM
Agile Business Analysts, Melbourne
Melbourne - Australia
Tuesday, August 13 at 6:00 PM
Agile Business Analysts, Melbourne
Melbourne - Australia
Tuesday, September 10 at 6:00 PM
Agile Business Analysts, Melbourne
Melbourne - Australia
Tuesday, October 8 at 6:00 PM
Agile Business Analysts, Melbourne
Melbourne - Australia
Tuesday, November 12 at 6:00 PM
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.
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.
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
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
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Â
Agile Consultancy of the Year: Indigo Blue
Who were a sponsor…
Best Agile Team: The Guardian
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
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
Most Valuable Agile Player (UK)
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…
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:
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.
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
Happier Employees Give Companies Better Returns. Makes sense doesn’t it?
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 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.
- 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
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.
- 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.
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.
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.
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.
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.