Building something correctly vs building the correct thing. Agile Mindset implemented correctly delivers to both sides.
Product Owners defines what needs to be delivered, Architecture determines the feasibility and how the products will be delivered and finally the Development team will do the actual delivering.
Things can go awry if all three key parties are not communicating, empowering and trusting each other. Architects, in particular, can have a huge impact in defining what enablers need to be in place for the Development Team to work against. However, they should take into account expert feedback from the team in terms of tools and techniques (and not consider themselves as the only experts in the team) otherwise, there is a huge risk of over-complicating the solution for the sake of using bleeding-edge technology.
Additionally, getting your products in front of customers is so darn important to ensure that you are delivering to their expectations AND can adapt accordingly to any gaps. The whole premise behind a great Agile mindset is soliciting for and accepting early feedback from the customers. Immature product owners will frequently see the release of minimal features to have a negative impact on the customers, but provided that expectations are properly set, customers are the single most important source of feedback that the Development team can use to deliver something the customer expects and needs.
The Product Owner while being the business and market expert is still not the customer.
And in saying all that, strive to deliver in as cool a way as possible 🙂 After all, the journey matters too! 🙂
Increasing the Agile mindset and creating higher performing teams can pose quite a bit of a challenge even to the most experienced of agile coaches.
Will endeavor to set up a weekly post with a small collection of hints and tips and gotcha’s to avoid 🙂
“Just Good Enough”…
Being Agile doesn’t translate to no documentation. Instead, in Agile Scrum, documentation should be “Just Good Enough“. Traditionally, entire cottage industries are created through the need to document and audit everything. This is not necessarily so true in Agile. Stories and Tasks are documented just enough to cover the delivery of the feature. Once the feature is delivered, it is very rare for anyone to refer back to old stories and tasks.
Having too much documentation will run the risk of becoming mini-waterfall within your sprints.
Epics and Feature Briefs
Epic and Feature briefs are small one-pagers that describe at a high level the epic or feature being developed and has sufficient information to allow for meaningful conversations to take place. If you are seeing mini-project initiation type of documents detailing each epic or feature, you are running the risk of over-documentation.
Avoid distributing risks and assumptions across these briefs. Instead have a central risk and assumptions area in your wiki/team space and link the relevant epic or feature Id there.
Documenting User Stories
Documenting user stories should follow the INVEST rule and focus on having sufficient information to allow a delivery team to have a conversation with the product owners and break the story down into technical tasks as part of their sprint planning.
I will not explain INVEST here – there are many great articles on the web that can do that significantly better than I can 🙂 The main purpose here is to ensure that there is enough for that conversation to take place.
Gotcha #1: Technical teams may start breaking down their tasks as per the screen wireframes (instead of taking each story). This will result in a disconnect between the stories and the tasks. A screen wireframe may have multiple stories within it, but the team may have difficulty in assigning the right tasks to the right story.
The result will be a single story that will suddenly have a lot of tasks in it and other stories with zero tasks. If you see this, stop immediately, and re-focus the delivery team to work off the stories themselves and not the wireframes in isolation.
It is also useful for the team to have a holistic view of the wireframe screen they are delivering, and possibly superimpose the story cards over the screen. This gives them the overall view of the screen and expected behavior and still allow them to go into detail as required.
It is key to review the stories and tasks and ensure traceability between the “what/why” and the “how”.