A little while ago in a private Agile forum I saw a post by a person who was very frustrated with Agile.
Their main concern was over the manifesto value “Working software over comprehensive documentation”. The scenario that they presented was one, where as a Product Owner, they wanted to understand a few of the business rules that the product had within it. They were informed by the product development team that they would need to create a user story for it, prioritise it against the backlog and when it hit the top of the queue it would get done.
Now the Product Owner chose to put it midway through the queue, but they were still unhappy with the fact that given the team’s backlog it would mean they would get their answer to what they felt was a simple question in two months time.
Why can’t I have just some documentation so that I don’t have to wait two months to get an answer on this? If we were still using waterfall we would have the answer right now.
A few people responded that Agile doesn’t mean no documentation, that there is often the documentation that is needed, but obviously this was one of the rare cases that the needs were greater than normal.
My thoughts on the problem raised were almost completely different:
- By not spending time documenting everything the team would have saved time over a prolonged period. If the team had spent time documenting everything to the nth detail then it might have taken a total of two or three months additional effort, for something to only be requested once. Now think about how much extra development work, actual beneficial changes to the customer, that they would have delivered in that time.
- The Product Owner chose to prioritise this knowledge below half of the outstanding work. It was always in their power to make it the highest priority item if they wanted to.
- There is a bigger issue that is being ingored or overlooked – the fact that the team had a four month backlog. I am not saying that a four month backlog is wrong, I am saying that a four month backlog is worthy of investigation to see why it is so long and whether something can be done about the constraints in the system to lower it. Think about how the team may feel knowing that there is four months of work hanging over their heads. They are unlikely to feel inclined to innovate knowing that there is so much that the product owner still wants delivered.
Do you think if the backlog was only a week long that the original forum poster would have made a comment about the Agile manifesto not working? Of course not, they would have waited only a week to find out that information and the team would have been considered responsive in their eyes.
Read Full Post »
Posted in Agile, Lean Startup, Scrum on November 28, 2012 |
5 Comments »
Seven years ago I was involved in an open debate at an IIBA meet up on the role of Business Analysts within an Agile environment. At the time my opponent contested that Business Analysts were defunct under Agile and were no longer required. I debated that they were still needed but that their role changed somewhat.
My main argument was that they were no longer the provider of lengthy requirements documents written in advance with little to no collaboration in the team. This didn’t mean that Business Analysts were no longer required to write any form of documentation, just the amount of documentation, the collaboration involved to reach a common understanding and the timing of when the documentation is done changed. With this reduced amount of time directly spent writing ‘War and Peace’ requirements they would instead use their time in a new skill set – as facilitators. I saw the role of the Business Analyst as being very compatible with the Scrum Master role, where the Business Analyst could encourage an environment of collaboration and ensure that the ‘promise for a conversation’ occurred. Business Analysts would still need to have skills drilling into the root cause of problems, to understand and analyse and question the business process, but in a good Agile team everyone would also have this skill.
Time has moved on and most of what I predicted for the Business Analyst role has come to pass within Agile environments. But I believe that it is time to make a new prediction.
We have come a long way towards mastering the art of building the product right, our next journey is to build the right product. After all, according to Lean principles, the biggest waste is the waste of overproduction and this can take the form of producing an unneeded or incorrectly targeted product.
Thus, in today’s ever shifting environment, I see the role of the Business Analyst as that of being at the heart of data. I see the role transforming to focus more on data analytics and the understanding of data associated with the product. Some may say that this is the role of the product owner, to which I probably wouldn’t disagree with and as such I see the Product Owner and the Business Analyst roles merging even closer together but with an incredibly strong focus on data.
So what is all the data that is being analysed about? Four things:
- Are we improving the number of customers seeking our product?
- Are we retaining our existing customers?
- Are customers getting value out of our product?
- Is our product revenue model generating net profit?
If the answer is yes to the above questions, founded soundly on data then your product is in a great place. If you cannot answer these questions then you really should start working on it (before you go out of business). For those of you familiar with the Lean Startup model then the above discussion should be something very familiar to you, for I believe the Business Analyst role should be centered around enabling the data gathering to support a Lean Startup approach.
You don’t have to be a start up to gather this data. You don’t have to measure once every three months. You can start measuring your existing product and incrementally improving on the four questions right now and everyday from this point onwards. Armed with this data you can know whether a change you made today will make a difference to your business tomorrow.
Maybe the role shouldn’t be called “Business Analyst” anymore . Maybe we should start to create “Product Analyst” roles instead?
Read Full Post »
I am currently in progress of writing my first Agile book. It is basically a beginners Agile book targeted outside of the software development industry with a major twist.
If you would like to participate as a reviewer can you please contact me via twitter with an @AgileRenee mention and then I will send you a direct message to get your email address (if I am not already following you, otherwise just DM me). Alternatively you can email me at firstname.lastname@example.org
Read Full Post »