My presentation at Scrum Australia 2016 titled “Lean Discovery” is available on Slideshare.
“The hardest part of building any software system is determining precisely what to build.” – Fredrick Brooks.
Discovering exactly what customers, stakeholders, and sponsors want to create is often the most difficult part of product development. Getting everyone aligned can be fraught with misunderstanding and misinterpretation. Scrum starts with a product backlog, but how do you know that the development of the product supports the growth of your company?
Getting off on the right foot when starting an agile initiative can set you up for success. This presentation will outline a basic flow of light touch Discovery workshops as a way to start your agile product development engine.
And here are some of the tweets from the session:
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!
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”
Agile welcomes changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Short feedback loops in Agile allow the team to get fast feedback and incorporate changes required by the customer and reduce the possibility of the team developing the wrong product for too long.
The Product Backlog is dynamic and evolves over the lifetime of the product and requires constant grooming and refinement. The Product Backlog is continuously updated by the Product Owner to reflect changes in the needs of the customer, new ideas or insights, moves by the competition, technical hurdles that appear, and so forth.
During an iteration, the Agile Team should invest some time to work with the Product Owner to refine the Product Backlog (a.k.a. Product Backlog Grooming). This includes requirements analysis, splitting large items into smaller ones, estimation of new items, and re-estimation of existing items. Priorities can change and requirements can move up and down in the Product Backlog. When new items are discovered, they are inserted into the Product Backlog causing the lower ones to move down the list (and possibly fall outside of the scope of the release) or old requirements removed as appropriate.
Although Agile welcomes changes, when using time-boxed delivery like Scrum, there are no changes allowed during the iteration, and the end date of the iteration does not change. In return for not making changes during the current iteration, the Product Owner can make any changes they want to the Product Backlog before the start of the *next* iteration. The Product Owner can add, remove, reorder, or change items before the start of the next iteration. This enables the Agile team to make and keep commitments, it gives the team focus and stability during the iteration, and it trains the Product Owner to clearly think through what is in the Product Backlog. Due to the short time-boxes, the team should be able to get some reasonable certainty into the planning and requirements and avoid churning during an iteration.
Overtime if you find that the Product Owner keeps needing to change requirements mid-iteration, then perhaps the iteration length is not short enough. Plan iteration durations around how long you can commit to keeping change out of the iteration.
If you have been following my blog, you will notice that Dilbert comics seem to jolt me into writing a new entry. In this comic, the pointy-haired boss actually makes a wise comment when he says “Just break into whatever size groups you think make sense”. For Agile teams, what make sense is small teams. I like how Amazon.com refers to their teams as “two-pizza teams” meaning that the team can be fed by 2 large pizzas. If they can eat more than 2 pizzas, then the team is too large.
Scrum guidance states that team sizes should be between 5 and 9 people and this is no co-incidence to the paper The Magical Number Seven, Plus or Minus Two. Smaller teams are more effective because people can’t remember more than 7 things at a time – team members need to know what each other is doing. There are many benefits of smaller teams so if you need to scale up a project, add more teams than making existing teams larger. Remember to keep it to two-pizzas
I have been a fan of Mike Cohn and his latest book Succeeding with Agile: Software Development Using Scrum is another great book. He blends a good mix of theoretical and practical techniques drawn from his past experiences. This book doesn’t show you how the Scrum Framework works, but it is more of a cookbook of good practices and suggestions that you can help you succeed with Scrum. So if you are new to Scrum or looking for an introduction to Scrum I suggest you read some other sources first such as the Scrum Guide (by Schwaber and Sutherland) or the Scrum Primer (by Deemer, Benefield, Larman and Vodde) and then coming back to this book for tips and advice as you implement Scrum.
I was able to relate to some of Mike’s observations with my own experience and found myself nodding my head in agreement to some of his sections on ‘objections’ and various stories throughout the book. As a result, the book felt very personable as I felt like I have been there done that. He does offer some practical advice when dealing with the various ‘objections’ that you may encounter along the way. He also points out the challenges in adopting and transitioning to agile. The following is an important quote from the book:
I’ve personally witnessed several failed agile adoptions that could have been prevented. The first was in a company that had spent more than a million dollars on its transition effort. Executives brought in outside trainers and coaches and hired five people into an “Agile Office” to which new Scrum teams could turn for advice. The company’s failure was the result of thinking that the implications of adopting Scrum would be restricted to only the development organization. The executives who initiated this transition thought that educating and supporting developers would be sufficient. They failed to consider how Scrum would touch the work of salespeople, the marketing group, and even the finance department. Without changes to these areas, organizational gravity pulled the company back where it had started.
A common theme throughout the book is that there is no ‘standard’ way of doing agile and that it must be adapted to the organizational context and project. He devotes a whole chapter, ‘ADAPTing to Scrum’ [Chapter 2] to this topic.
Although it is mainly centered on Scrum, Mike describes various other techniques and methods to produce a handbook that is thorough and complete for any Agile practitioner. Scattered throughout the book are real-world case studies drawn from the Mike’s experience helping many software organizations adopt Scrum, and ‘things to try now’ sections based on his advice offer practical, quick ways of coming up to speed fast. I really liked the chapters on New Roles [Chapter 7] and Changed Roles [Chapter 8] where he describes the 3 key Scrum roles but also identifies how the traditional roles changes to fit into an agile development framework.
I highly recommend reading this book as part of your Agile training, whether you are implementing Scrum for the first time or an experienced practitioner. It is an easy and good read.
This recent Dilbert comic strip reminded me of a situation when a client was raising cosmetic defect as severity 2.
It is often not clear what a defect is and at what level to raise it at (despite agreed severity descriptions) as my example above shows. And some defects are raised without being related to a requirement. Or defects raised because of a feature being “not user friendly”.
Regardless of the reason and how you label the ‘defect’, I treat all defects the same – it is a piece of work required by the client that needs to be prioritized with other work. So the approach is to put all work (defect, enhancement, new feature etc) into the product backlog. As part of the planning process, the Product Owner will prioritize the items on the backlog for the next iteration and/or release. So if a cosmetic defect is more important (has greater business value) than a new feature, then it should be placed higher so it gets completed first.
Keeping all work in the product backlog, makes planning simpler and helps manage the flow of work. It also ensures the client is in control and be the judge of what is important to their business.
I came across a nice analogy today in Mike Cohn’s Succeeding with Agile book which describes what sustainable pace means:
Watch any marathon, and each runner will keep it up for 26.2 miles. Look more closely, however, and you’ll notice that the pace is not entirely consistent from mile to mile. Each works a little harder going up the hill and maybe recovers slightly coming down it. At the finish line, most accelerate and sprint at a pace that is not sustainable beyond the finish line.
Sustainable pace should mean the same to a Scrum team: Most of the time the team runs at a nice, even pace, but every now and then team members need to kick it up a gear, such as when nearing a finish line or perhaps attacking a critical, user-reported defect.
Working overtime occasionally does not violate the goal of working at a sustainable pace. Some overtime is justified. Do overtime only when we are in critical situation but do not to make it daily or frequent practice as it affects efficiency, productivity, morale and quality. Consistent and extended overtime is a symptom of a serious problem on the project. It is even more serious when overtime is scheduled into a plan.
Teams cannot be pushed infinitely hard and beyond a certain point, working more hours in a week will move the team backward rather than forward.
Don’t automatically assume overtime equates to actual progress or delivery of value. Often overtime just means that people are present longer, but they aren’t working more. Many studies, in different industries, have shown overtime hours to be far less productive than normal working hours.
When overtime is consistently required, we need to address the cause not just the symptoms. It is a learning opportunity of our capability to schedule and rethink how we reschedule. What is it about our scheduling approach that produced an incorrect plan? Agile is about inspecting and adapting our approach and learning as we go along.
Joe Townsend has written an article along the lines what I have been saying for a while now – in Agile there is no ‘best practice’, and as Townsend puts it
What works for you, your team, division, corporation, etc. can bring another person, team, etc. to a screeching halt.
In particular, one needs to be very careful when trying to take waterfall best practices and trying to apply it to an agile context. Many of waterfall concepts and best practices are counter-productive and ineffective on agile projects.
Its only semantics, but the term ‘best practice’ often means this is the best way to do things and trumps all other approaches. I prefer the use the words ‘lesson learned’ or ‘guidance’. What one or more teams have done, should be used as a lesson learned that is to be adapted to the environment you are applying it to and used as guidance. No practice will work for everyone or every team in every context.
Before applying a lesson learned or guidance, you should ask yourself does it make sense and does it align with agile values and principles? Does it help me deliver software more quickly to my customers? Does it help with achieving technical excellence? Remember to discuss with the team before using any lesson learned or guidance.
Despite that we are still yet to finish the current scope of work for the Agile Initiatives, we are starting to discuss future items in our backlog – distributed Agile and Agile@Scale.
There are a few projects in flight that couple of colleagues are working on that are large Agile programs of work. Large-Scale Agile by James Shore provides an insightful and thoughtful approach.
On a past project we used a similar technique mentioned in James Shore’s post to Using Bounded Contexts to Minimize Dependencies and Using Kanban to Manage Cross-Team Workflow. Though we didn’t use Kanban specifically, the outcome of the approach was similar – when the Team A is ready to work on something new, they took the next item off of the backlog, work on it until it’s done, and then delivered it to Team B that requested it. Where this feature is prioritized in Team A’s backlog is dependent on when Team B needed it.