Agile Practices Category
This webinar was recorded in June 2014. I was on a panel with Bernd Schiffer discussing the role of a BA in large agile environments hosted by Pete Cohen. I forgot to post this at the time and although it was two years ago the discussion is still relevant today.
Thanks to Lynne Cazaly for capturing the following visual notes of the session.
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:
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”
I have been asked countless times “how is documentation managed on agile projects?” or “can you give me a template for agile documentation”. I have also heard statements like “we do not need to do any documentation when using agile”. And more recently I was asked “how do I best document an agile build as it progresses….I want to build up a picture of what it does by documenting the requirements”.
To start off, let’s get one thing straight – documentation does actually exist under agile, albeit not in a traditional sense. One of the most common misunderstandings is that agile = no documentation. Agile is not anti-documentation or agile does not disregard or exclude documentation. If you look at the Agile Manifesto, it states Working software over comprehensive documentation. Now where does it state that there is no documentation? The intent of this statement is that whilst documentation is important, the real value is producing working software that does something valuable for the business.
Anybody who actually works with code or close to the coalface knows that (overly) detailed and comprehensive documentation ages very quickly and actually becomes an impediment to respond quickly to business change as it diverges from the source of truth (the code).
One of the Agile Manifesto Principles that sums up the approach to documentation very succinctly and that is simplicity the art of maximizing the amount of work not done is essential. Let’s be pragmatic on what documents are really needed and keep it simple. Simple in number of documents needed, simple in the amount of detail and simple in the formality. Like most agile approaches, we produce just enough documentation. Keep documentation lightweight and simple – wikis are great and photos taken with a (phone) camera of whiteboard sketches often suffice.
The question you should ask yourself is what “value” does the document add to the process? What purpose do the documents serve? Who is the audience?
Documentation to aid collaboration has a different purpose to documentation that is needed for prosperity purposes. Thinking about documentation in these two types helps decides how we go about it. Documentation for collaboration should be kept as light wight as possible (and can be a thrown away when done) as we prefer people collaborating with each other face to face. Treating documentation for collaboration as if it was for prosperity often slows us down as the amount of detail and the content is quite different.
- Story cards
- Story walls
- Flip charts
- Agile Management Tools
- The code
- The tests
- Recorded demos
- (Valuable) documents
There needs to be a pragmatic balance of documentation (requirements, architecture, design) along with well structured, clean and readable code.
Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API. Code should be literate since depending on the language, not all necessary information can be expressed clearly in code alone.
— Dave Thomas, from Clean Code by Robert Martin (“Uncle Bob”)
This is an example where disciplined agile engineering practices is vitally important to the agile process. Don’t be afraid to rely on team member to team member communication to distribute knowledge about the system. Use pair-programming to share understanding with others so there are no dark areas and less need for people to document what has happened.
Another recent question I was asked is “how is business modeling handled in agile?” The Agile Modeling website provides some guidance. By Agile Modeling I don’t mean just UML – think ‘just barely good enough sketches’ on whiteboards – everyone should be comfortable bringing them on and in the language of the domain (ubiquitous language) – see Eric Evans’ Domain Driven Design. Domain Driven Design provides some guidance on how you think of the domain, the language you use to talk about it, and how you organize your software to reflect your improving understanding of it.
Automation of tests is important at both the whitebox (unit tests) and blackbox (functional) levels. These automated tests describe the behaviour of the system at the code level and functional level and as such by nature are a form of documentation themselves. For example, a glance through a suite of functional tests, you should be able to get an understanding of the functionality of the system. Unlike documentation, there is no fear of automated tests getting out of date as these will be constantly maintained to reflect the behavior of the system. Therefore, clean code and automated tests are seen as the primary repository of detail on how the software was implemented.
There is no one right answer as to what documentation, how to write it, and who should create it. However, constantly ask yourself before producing a document whether it is worth the effort to create and maintain it. Keep documentation simple and produce just enough. Documentation doesn’t have to be perfect – it just needs to be good enough for the purpose they serve. Once there is no use for it, stop producing it.
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.
Here’s a great and short slide deck on Agile Retrospectives so you can get the most out of it. Many are not utilising retrospectives effectively to drive team improvement. It is more than just asking what went well, what could be improved for next iteration and what will we do differently for the next iteration.