Yesterday I passed the PMI – Agile Certified Practitioner (PMI-ACP) exam with Proficient results. Woo Hoo!!
I took a very very light weight approach to my preparation. I am currently very time poor which has led me to do minimal and just enough study.
I did not read any of the prescribed reference books for the exam (I have no time) – there’s 11 of them (ouch)!!! But I have read parts of some of the books at some stage in the past. The only book I read once 4 months ago was “The PMI-ACP Exam: How To Pass On Your First Try” by Andy Crowe. In hind sight after completing the exam, I didn’t find this book very useful in that I didn’t learn anything that would prepare me for the exam.
A few days prior to the exam, I used http://www.agileexams.com as a guide to what to study. Whenever I got an answer wrong I would do a short study spike by researching the topic. Most of the time the questions I got wrong on the practice exam were ‘off-the-road’ agile concepts or ensuring I got the ‘text-book’ agile theory right. As most would know, there are various approaches and adaptations in agile that would work, but for the exam you are tested for the theoretical correct approach. I would recommend using agileexams (I found it useful) as a study/prep tool as a way to hone in on study gaps.
I am an agile practitioner and have been coaching agile for a number of years now so the above light weight, minimal marketable reading approach worked for me. I suspect if you have agile experience, then passing the exam would not be too difficult without having to read all the books too.
For the actual exam I took 3 iterations, 2 hours in total (you have 3 hours to complete the exam):
- Iteration 1 – Went through all the questions and selected the best answer. Marked about 20 questions to review (60mins).
- Iteration 2 – Reviewed all the marked questions (15mins).
- Iteration 3 – Went through all the questions again to double check my answers (45 mins).
In most cases, 2 answers can be easily ruled out (i.e. obviously incorrect). There were a few instances where in practice several answers would be plausible, but there was only one theoretical and ‘correct’ answer for the exam.
Good luck if you are planning to take the exam!
Now that I am PMI-ACP certified, what now?
Last week I attended the LAST Conference (Lean, Agile, Systems Thinking) held at Swinburne University. The LAST Conference is a big departure from the Agile Australia 2012 conference I attended earlier this year. There was no fanfare, no big build up, little corporate advertising and significantly less people. It was also only $50 for the whole day but still contained lots of learning opportunities. It lived up to the advertised “low cost, grassroots mini-conference” message.
The conference schedule contained 5 parallel tracks so it was hard to attend all of it. I found myself at times wandering between sessions to get sound bites of what people where talking about. Being held at a uni one thing I definitely liked was the university lecture theatre style of some of the sessions – it felt right compared to sitting in a large conference center. Unfortunately, I couldn’t stay for the last sessions as I needed to head back into work.
I didn’t take any detailed notes, but here are my takeaways (in no particular order):
- Systems Thinking is the opposite of scientific thinking. Systems Thinking is not:
- Rocket Science
- Sea of Systems a handy guide to Systems Thinking
- Invention is the process of discovering something new or come up with an idea. Innovation is the act of of introducing that idea into the market and commercializing it
- Played some neat games that help with agile learning.
- Stages of learning:
- Unconscious incompetence
- Conscious incompetence
- Conscious competence
- Unconscious incompetence
- I had lots of fun in the Visual Collaboration session fine tuning my sketching skills. Use Wong-Baker Faces to visually represent levels of pain.
- Lots of interesting tidbits some of which I already knew but others just heard of in Edgy Agile things.
Here’s a selection of twitter posts on the conference (#LASTconf):
- @RonicaRoth: #LASTconf motto: you are not an attendee. Excited to participate!
- @lynnecazaly: Story structure: people + place + trouble …people want to know why, why this, why different #lastconf @unorder
- @hwiputra: A good storyteller uses concrete words not abstract words #LASTconf
- @hwiputra: Be comfortable with silence when getting stories out #LASTconf
- @AgileRenee: #LASTconf how to measure value? IRACIS – improved revenue, avoid costs, improved service
- @AgileRenee: #LASTconf my answer: the biggest waste in software dev today is doing the wrong work (benefits to cost don’t stack up)
- @libodyssey: culture is the product of behaviour #lastconf
- @ScrumMasterNZ: Work towards “Decision Meetings” and not “Status Meetings” #LASTConf #agile #lean
- @jodiem: Eg this guy has 3 levels of backlog – team-product , release-quarterly and sprint… #confused #lastconf
- @CEPitchford: The motivation for #offshore at REA was not cost it was talent! #win @hwiputra @frankmt #LASTconf
- @CEPitchford: Standup with #offshore team via Skype was hard. We couldn’t understand each other @hwiputra @frankmt #LASTconf
- @CEPitchford: Was hard for Chinese #offshore team to get visas to come to OZ @frankmt @hwiputra #LASTconf
- @CEPitchford: The whole local OZ dev team went to china for 3 weeks to handover to the #offshore team #LASTconf
- @AgileRenee: Find I’m mentally disagreeing with a lot said in the offshoring session in #LASTconf we have talent and should invest in building it locally
- @jodiem: Self service test environments… Where QA env is exactly the same as production env. Cool #devops #lastconf
- @antomarsh: Team rotation from Aus to China critical #LASTconf
- @gusbalbontin: Words such as “framework” and “governance” should never be in the same sentence as the word innovation. #LASTconf
- IrithWilliams: #Lastconf the real job at a standup is to ‘listen, inspect, adapt’
- @magia3e: Too many context changes slows down the #scrum team. Focus on getting to-do done #LASTconf
- @rooosterboy: How is #LASTconf different to #agileaus ? Seriously.
- @magia3e: If u don’t have some sort of continuous integration toolset/capability it will limit your velocity #LASTconf
- @c2reflexions: @AgileRenee doing a song and dance at #LASTconf
- @magia3e: Document the right stuff, but don’t waffle it out. Cut to the essence of it. communicate it with the right collaborative tools #LASTconf
- @CEPitchford: More control from management = less innovation from empowered teams #LASTconf @frankmt
- @CEPitchford: It’s not about execution anymore. It is about learning. #organizationalchange #LASTconf @frankmt
- @CEPitchford: Change programs: do we actually want to change? Or adapt, innovate and LEARN? #purpose #LASTconf @frankmt
- @CEPitchford: The way we still run companies was invented by people who lived in the last century @frankmt #LASTconf
- @CEPitchford: Project schedules and budgets are a work of fiction anyway @brown_note #LASTconf #fishbowl
- @hwiputra: All good leaders believe in their teams. #LASTconf
- @Drew_1609: Best value and most fun conference attended in a long time #lastconf
- @njhoughton: MVP … what’s the minimum thing to go-live … hold this as a meta-frame as you sprint … my examples are #foresight and #Innovation #lastconf
The visual recordings by @lynnecazaly were done using the iPad Brushes app. I have downloaded the app and now I just need to brush up (no pun intended) my skills. Thanks Lynne for the inspiration to try visually recording my notes.
Thanks to the organisers, Craig and Ed for putting together this great event. Snaps!
Recently a colleague and I were facilitating an agile project initiation workshop. To help the team to come up with ideas and formulate solutions for the problem they were trying to solve we used a method that combined the Walt Disney Creativity Strategy and Ritual Dissent.
The Walt Disney Creativity Strategy
The Walt Disney Creativity Strategy is a practical creativity process used by Disney to turn fantasies into concrete and tangible expressions and was used to create many of his classic animated films we have grown up to love such as Snow White, Pinocchio, Bambi and Fantasia.
One of the major elements of Disney’s unique genius was his ability to explore something from a number of different perceptual positions. An important insight into this key part of Disney’s strategy comes from the comment made by one of his animators that,
“…there were actually three different Walts: the dreamer, the realist, and the spoiler (critic). You never knew which one was coming into your meeting.”
This was not only an insight into Disney but also into the process of creativity. Creativity as a total process involves the coordination of these three sub-processes: dreamer, realist and critic. A dreamer without a realist cannot turn ideas into tangible expressions. A critic and a dreamer without a realist just become stuck in a perpetual conflict. A dreamer and a realist might create things, but they might not achieve a high degree of quality without a critic. The critic helps to evaluate and refine the products of creativity.
Everybody has the Dreamer, Realist, Critic inside them. Unfortunately, what usually happens is that the Dreamer and the Critic get into a fight. If you take a typical business meeting, you can have a Dreamer, a Critic and Realist in this meeting. Rather than functioning in some organised strategy, the Dreamer says something, the Critic argues against it, then the Dreamer has a polarity reaction to the Critic. The Dreamer and Critic go in conflicting directions until, finally, the realist says, “We’re out of time.”
In addition, one of the biggest problems is that the Critic doesn’t just criticise the dream. The Critic criticises the Dreamer. Part of why Disney could function so effectively is that he didn’t criticise his team or himself, he criticised the plan to accomplish the dream. The purpose of the critic is to insure that something meets certain criteria. What keeps the Critic and the Dreamer from being stuck in a polarity response is the Realist.
The three distinct stages of the creative cycle addresses different questions:
- What you want to do? (As opposed to what you want to stop doing, avoid or quit).
- Why do you want to do it?
- What is the purpose?
- What are the payoffs?
- How will you know that you have them?
- Where do you want the idea to get you in the future?
- How specifically will the idea be implemented?
- How will you know if the goal is achieved?
- How will the performance criteria be tested?
- Who will do it?
- When will each phase be implemented?
- When will the overall goal be completed?
- Where will each phase be carried out?
- Why is each step necessary?
- Does this plan match the criteria and purpose for which it was intended?
- Why might someone object to this new idea?
- Does the idea all fit together and is cohesive?
- Who will this new idea effect and who will make or break the effectiveness of the idea and what are their needs and payoffs?
- When and where would you not want to implement this new idea?
To facilitate the creative strategy, Disney had different rooms for the Dreamer, Realist and Critic. The ideas moved between the three rooms:
- Dreamer Room: This room had inspirational drawings and sayings all over the walls. This was the place were wild ideas and thoughts were born, no restrictions, no limits. Criticisms were not allowed – only dreams!
- Realist Room: This room contained all the tools and instruments that were needed to manifest the dreams. The room was arranged so everyone could see and talk to each other in a collaborative space. Here the dreams that were created in the Dreamer Room were put onto ‘story boards’. (The concept of story boards are also used in agile analysis, although they are more often referred to as user journeys or scenarios).
- Critic Room: Also known as the ‘sweatbox’ as it was located underneath the stairs and was cramped and hot. This is where people would critically review and evaluate the ideas (not the individuals).
The below table summaries the pattern associated with Disney’s creative strategy:
|Time Frame||Long Term||Short Term||Long & Short Term|
|Time Orientation||Future||Present||Past & Future|
|Reference||Internal – Self||External – Environment||External – Others|
|Mode of Comparison||Match||Match||Mismatch|
Ritual Dissent is a workshop method designed to test and enhance proposals, stories, ideas or whatever by subjecting them to ritualised dissent (challenge) or assent (positive alternatives). In all cases it is a forced listening technique, not a dialogue or discourse.
The basic approach involves a spokesperson presenting a series of ideas to a group who receives them in silence. The spokesperson then turns their chair, so that their back is to the audience and listens in silence while the group either attack (dissent) or provide alternative proposals (assent). The ritualisation of not facing the audience de-personalises the process and the group setting (others will be subject to the same process) means that the attack or alternative are not personal, but supportive. Listening in silence without eye contact, increases listening.
The Workshop – Combing the two approaches
One of the goals of the agile workshop was to come up with ideas and formulate solutions to solve a business problem. When coming up with ideas we want to quickly know if it will work or if the plan is achievable. We want the ideas to fail fast so we can succeed sooner.
We created a process to get fast feedback on ideas by drawing on elements from The Walt Disney Creativity Strategy and Ritual Dissent. The following steps describes the technique we used in the agile workshop:
- Split the group into 2 teams (or more). We ensured we had a good balance of skills and knowledge in each of the groups (eg business SMEs, developers, architects, business analysts etc).
- Each group went to separate rooms. Taking a Dreamer strategy, the group members worked together for 2 hours to dream up ideas, and develop solutions to the problem space without any limits. The groups also represented their ideas by drawing up a story board or visual map of the problem space.
- A spokesperson from one group (Dreamer) would present their ideas, explain them and the criteria and assumptions behind them in 6 minutes to the other group (Critic) who receives them in silence.
- We then allowed 3 minutes of Q&A time to allow the Critics to clarify the ideas with the Dreamers.
- We asked the Critics to turn and face the story board or visual map containing the idea so their backs were towards the Dreamers. The Critics then proceeded to criticise and dissent the ideas through verbalisation and placing post-it notes on the story board/visual map. The Dreamers received the dissent in silence.
At this stage we could have also asked the Dreamers to turn their backs to the Critics, but thought as long as the Critics were facing and dissenting the story board or visual map and therefore criticising the ideas, it was enough to de-personalise the process.
- Steps 3 to 5 were repeated with the groups switching Dreamer and Critic perspectives, so the group that was presenting their Dream become the Critics. And the Critics become the Dreamers.
- Each team then returned to their room clarify specific steps and actions by exploring the Realist questions and identifying ways to make the dream real based on the Critic’s input and feedback. The Realist then transcended to Dreamers once again to refine and come up with the next approximation (improvement) of the idea.
- We time-boxed the activity which only meant we had time to repeat the above cycle once more (two in total). We then combined the best ideas from the two different groups to form a single idea.
By following agile principles we only needed to do ‘just enough’ to get us to the next stage of the project where we can then iteratively refine the idea. But in practice, you can repeat the above steps as appropriate until you get a more grounded and improved idea.
If you had more than two groups, the Dreamers should present their ideas to a different group of Critics from previous ones to get new criticisms and viewpoints.
Throughout this process, the Dreamer focused on the ‘big picture’ with the attitude that everything is possible. The Realist acted as if the dream is possible and focuses on the formulation of a series of successive approximations of actions required to actually reach the dream. The Realist phase is more action with respect to the future, operating within a shorter time frame than the Dreamer. The Realist is often more focused on procedures or operations. Its primary level of focus is on ‘how’ to implement the plan or idea. The Critic seeks to avoid problems and ensure quality by logically applying different levels of criteria and checking how the idea or plan holds up under various “what if” scenarios. The Critic phase involves the analysis of the plan in order to find out what could go wrong and what should be avoided.
Using the Ritual Dissent approach with the Critics facing the idea (story board or visual map) rather than the individuals de-personalised the feedback subjected by the Dreamers. And finally, using the forced listening technique, not a dialogue or discourse of Ritual Dissent also enabled fast feedback without getting into personal conflicts and arguments.
We found the above steps and approach provided a harmonious process between the three stages of creativity. It incorporated the different points of view of the group members in the three creative cycle (Dreamer, Realist, Critic) to get supportive outcomes.
- How Pixar uses Agile like practices to make their movies
- Enlightened trial and error succeeds over the planning of the lone genius
Nordstrom is one of USA’s leading fashion specialty retailers and is a Fortune 500 company (2011 – ranked 254). When I think of a fashion retail company, innovation isn’t the first thing that comes to mind. So how does a large retail company like Nordstrom innovate? Through the creation of a Lean Startup team, called Innovation Labs. According to their website,
The Nordstrom Innovation Lab is a new, and growing, team. We act like a startup inside of a large company: we move through ideas quickly, using whichever technologies make sense. We also walk the agile walk: the lab is a collaborative workspace with stickies and note cards everywhere, and we follow agile engineering practices like pairing and test-driven development. On the customer-facing side, we use ideas from both lean manufacturing and lean startup, and test our experiments with customers using human-centered design strategies and tactics.
The below video is a brilliant case study on how the innovation lab uses Lean UX and human centered design to build an iPad application (to help customers select a sunglass) incrementally and getting customer feedback in real-time as they work, so they were never working on anything that wasn’t valued by the customer. They were only doing things that was delivering value.
The innovation lab manager, JB Brown states:
Somebody will have an idea and we will find a way to prove that the idea will work.
We really don’t know what the features are yet. We are going to use customer feedback as we go along in order to build the best thing. Building a feature and testing it until we get to the point where we have something that is good enough.
Building the iPad application isn’t complex and the cycle time to develop a feature wouldn’t take long. But what the innovation labs team has done is cut down the feedback loop times. If this application was built in an office away from the customer, getting feedback would have been much longer. And by getting feedback directly from the end users rather than a user proxy, they have reduced the risk of developing the wrong features.
The innovation lab uses a concept called ‘flash build’, a variation of a flash mob, where a software team shows up at a surprise location to build a minimal viable product application so they can get direct customer feedback in real-time.
It is awesome to see innovation and the use of lean and agile principles and practices in action within a large company.
I came across a great article by Masaaki Imai on Gemba Panta Rei celebrating Taiichi Ohno’s 100th Birthday which contained some of his brilliant quotes on management and thought I will re-post them:
“Let the flow manage the processes, and not let management manage the flow”.
In the lean approach, the starting point of the information flow is the final assembly process, or where the customer order is provided, and then the flow goes upstream by means a pull signal such as kanban. On the other hand, the flow of materials moves downstream from the raw material stage to the final assembly. In both cases the flow should be maintained smoothly without interruption.
Unfortunately, in a majority of companies today, the flow is disrupted and meddled with by the convenience of the shop-floor management.
“Machines do not break down; people cause them to break.”
His life-long pursuit was to make a smooth and undisturbed flow as a foundation of all good operations. He believed that wherever and whenever the flow is disrupted, there is an opportunity to do kaizen.
“The gemba and the gembutsu have the information. We must listen to them.”
Taiichi Ohno always placed respect for the worker first in his approach to kaizen. His focus was always on the customer, both external and internal.
“Just-in-time means that customer delight is directly transmitted to those who are making the product.”
Ohno was a man of deeds. Learning by doing was his motto and he did not engage in empty discussions. You pay money to buy books and go to seminars and gain new knowledge. But knowledge is knowledge, nothing more.
“Knowledge is something you buy with the money. Wisdom is something you acquire by doing it,”
But you gain the wisdom only after you have done it. The real understanding of the lean operations is gained only after you have done it. No matter how many pages you may read on lean books, you know nothing if you have not done it.
“To understand means to be able to do.”
Apple have been innovative in their great customer experience with their touch screen gesture controls in their iPhone and iPad products.
Is this video showing the ultimate form of usability (UX) – a baby using a product?
You will notice that the baby gets no response using the hand gestures from the magazine and thinks that her finger is broken….
Reading the paper on the train home from work I came across this article. Banning corporate email seems to be an extreme approach, but I do agree emails are sometimes a waste of time as its a poor form of communication. I think we have become lazy with technology and send too many emails when a face-to-face conversation or a phone call would be more effective.
According to Radicati, 294 billion (in 2010) email messages were sent per day. This means more than 2.8 million emails are sent every second and some 90 trillion emails are sent per year. Around 90% of these millions and trillions of message are spam and viruses.
So by the company, Atos removing emails from their corporate environment they avoid having people waste time or putting systems in place to manage the spam and viruses. By using instant messaging Atos employees can increase their communication effectiveness through two-way real-time interaction. Email is a broadcast mechanism and has little scope for real-time interaction. However, I can’t help to think instant messaging alone is still a poor form of communication when compared to other alternatives. It’s somewhere between email and phone conversation. I have added a few additional communication options, including instant messaging to the below chart first created by Alistair Cockburn.
Many instant messaging tools now support video (including audio) and desktop sharing – so combining instant messaging with video and desktop sharing would provide a better and more effective communication channel than instant messaging alone.
Email still has its place, especially in today’s reality when you have a global economy where teams are distributed across different countries with different languages and culture. And with this comes the reduced available timezone bandwidth that don’t allow the use of real-time communication channels.
According to the article in Digital Trends, the CEO of Atos Thierry Breton says
“It is not normal that some of our fellow employees spend hours in the evening dealing with their emails. The email is no longer the appropriate communication tool.”
“Companies must prepare for the new wave of usage and behavior. If people want to talk to me, they can come and visit me, call or send me a text message. Emails cannot replace the spoken word.”
For me, I agree with Breton and always prefer face-to-face conversation which explains why I find myself walking between office buildings in the city a lot.
Maybe some level of pragmatism is required to educate people on when and when not to use email rather than having a zero email policy.
Donald Gray has written a great and interesting article on Three Leadership Styles, based observations on managing traffic at an intersection. In the article the most successful leader is the one that sees people as “adults that most of the time they can take care of themselves, and that the role of a manager is to support these competent adults”. To be effective, the leader should not place themselves at the center of the management task so that they can be much more flexible and effective at the key management activities. A must read.
A sprint goal helps to enable the team to focus on for the next 2 weeks. What does everyone want the team to work on next?
The Scrum Guide [Oct 2011] states:
The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. As the Development Team works, it keeps this goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the Development Team expected, then they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint. The Sprint Goal may be a milestone in the larger purpose of the product roadmap.
A sprint goal will be met through the implementation of the appropriate product backlog items. Working with the product owner, stakeholders, customers and users, the team identifies the product backlog items it believes it can develop during the next sprint to meet this goal. However, like many things in agile a key concept is ‘negotiation’. A reason for having the sprint goal is to give the team some leeway regarding the functionality and technology it delivers. During the iteration, the team determines daily how to meet the sprint goal. If the work turns out to be harder than expected, the team might only partially implement the functionality. At the sprint review meeting, the opportunity is given for the product owner and stakeholders to review how and what was implemented – they review how the sprint goal has been met. If they are dissatisfied, they can make decisions about the product backlog, architecture, team composition or release plan.
For short iterations (e.g. two weeks), the sprint goal may not always add a lot of value. With a two week iteration the team’s work may be sufficiently described that their goal becomes “complete the backlog items we selected.” For some teams I’ve observed a sprint goal may be useful but usually having better thought-through product backlog items works better. For these teams having release goals may make more sense than sprint goals. The teams that benefit most from sprint goals are those who have longer iterations (e.g. four weeks) or have just a few large product backlog items, as the goal provides some guidance as what we want to achieve and focus on.
Here’s an iteration goal for a team:
“Finish the agreed forms, portlets and web pages for News and Media then pick up additional stories to increase the team’s velocity”
Whilst this goal is ok, it gives no room to negotiate – it’s a very ‘command-and-control’ type statement rather than a goal to work towards. A small tweak by removing ‘agreed’ would provide some room for negotiation – “Develop the forms, portlets and web pages for News and Media site”. In addition, the second part of the iteration goal, “[…] then pick up additional stories to increase the team’s velocity” may be better suited belonging in the team’s social contract rather than in the sprint goal. ‘Doing more story points’ is an indirect result from focusing on WIP limits, pull, removing blockers, being a collaborative team and continuous improvement.
I have seen some sprint goals simply stated as “Complete x story points”. This is a useless goal as it provides no focus on what to work on other than to do achieve a number of story points (which leads to other issues such as story point inflation). So what if we have delivered ‘x story points’ if we didn’t deliver what the customer wants or delivered no business value.
So the idea behind a sprint goal is for the team’s output to be evaluated against the goal rather than the specific product backlog items they selected (there is a subtle difference). In a way it gives the team the opportunity to say “Well we didn’t finish all the backlog items but we met the goal.” Instead of having a sprint where we just ‘do more stuff’ the sprint goal can provide a theme the team can work towards. A sprint goal could be:
“This Sprint we will allow users to do a basic search, and enable the results to be filtered and the view sorted”
“No battle plan survives contact with the enemy.”
— Helmuth von Moltke
Sooner or later you will have the business asking questions like “How much is it going to cost?”, “What will I get?” and “When can I have it?”. The honest answer to this which often provokes a reaction of surprise are: “How much do you want to spend?”, “Tell us what you want” and “As long as it takes” respectively.
Technology projects are complex and high risk, and in particular there is high uncertainty especially before any actual development taking place. The Cone of Uncertainty [McConnell] describes the uncertainty in estimates of software development project cost, effort, and duration, throughout the lifecycle of a project. The degree of uncertainty is very large at the beginning of the project, which is often when decisions are made about project pricing and contracts which results in unrealistic project plans and expectations.
Agile or traditional, estimates on duration and costs are inherently very vague at the beginning of a project. For some complex projects, this uncertainty can last much later in the development process.
We are so accustomed to fixed price, time & cost projects, but in reality they are anything but. None of this information is new. However, project sponsors consistently latch on to the initial estimates project managers propose for the schedule and cost of a project at the start when the least is known and when there is the highest variability. And because project sponsors don’t understand project complexity and other factors influencing cost and schedule when requirements change and emerge, they may see the project as a failure if costs increased, even if the changes improved the value delivered to the business. Unfortunately, business executives’ lack of understanding about project management influences their perception of IT project success and failure [CIO].
There is inherent uncertainty, even in well-run projects. This is especially true in projects that involve complex software, large systems, large development effort, new application domains, new users. Furthermore, unlike manufacturing or building a house software development is a creative process and largely knowledge work which does not fit a cookie cutter model. We need to recognize that the Cone of Uncertainty implies substantial risks for traditional fixed-price and fixed-scope projects. The Cone of Uncertainty indicates we cannot predict the future accurately and that we need to restrain from traditional thinking. If you can’t predict the future, don’t plan it in detail.
A barrier to agile is the lack of the comforting predictive detailed plan whereby we plan out the uncertainty in a project, plot the path, determine the end date and the cost then produce the nice reports along the way. Interestingly enough whenever we question “are those plans ever right?” the response is often negative. Yet we place so much faith in them and they absolutely have to be there because it would be too scary to proceed without one.
Agile practitioners will do an order of less magnitude less effort to come up with a plan and provide answers to the questions “How much is it going to cost?”, “What will I get?” and “When can I have it?” that are just as good and just as inaccurate as traditional approaches.
We strive to ask for exact answers when exact answers don’t exist (estimates are just an approximate judgment or calculation – it’s a guess, but we seem to forget that). Reality will come to light soon enough. Striving for exact answers typically results in both time and money being wasted with little improvement in accuracy of the estimates to show for it.
An agile project will come up with a baseline view of how much the project will cost and when it is likely to be finished. The only difference to traditional thinking is that agile is very explicit right from the start that this is not accurate and the team will strive to understand more as soon as we start working it. We want to get to the actual development effort where we regularly deliver high quality, working software that maximizes the business’ ROI.
There is an amazing feeling of relief when agile teams can become comfortable with uncertainty and a freedom to actually discover what is needed at the appropriate time. Instead of relentlessly following the pre-defined plan agile teams will adapt to the inevitably changing conditions.
Being on time, on budget and to specification means nothing when we have delivered the wrong product with low quality that has no business value.
So rather seeking the exact answers, should we be asking if we are delivering business value?