Did you ever had the feeling, your team could be better? Have a higher performance? Be able to produce better outcomes?
I'm not talking about successfully finished sprints versus failed sprints or the constant struggle to increase velocity.
I mean your product - that thing your team is building. May it be your company's product or a contract work for another company.
Thinking back a couple of sprints
I was part of a team that was doing good solid work. We had our stakeholders, a clear vision, we gathered requirements, collected ideas, made short term and long term plans and started to work. We produced good quality. I'd say, we were even quite proud about the results. It was exactly what our stakeholders wanted.
After over one year of working, we got more and more frustrated. We didn't understand it back then, but we had a substantial problem going on - and we constantly ignored it while trying to produce the best results for our stakeholders. This was phase one.
We kept going this way but with a slight shift of priorities: we got a new stakeholder. We started again: gather requirements, collect ideas, plan, work, repeat. Entering phase two.
This time, everything was faster. This phase lasted for about three months. Still not very clear about what problem we had (again!), we worked almost in the same way as before. All we tried to achieve, was to build the best solution. But actually, we never had a real chance.
To put a long story short: in the end, all of us were frustrated, miserable and demotivated. The key stakeholder resigned from the initial goal. The job was gone. Eventually, the whole team broke apart.
The omnipresent problem that hindered us from becoming successful
The whole time, we worked on building the desired solution. In an agile way, we thought.
We just missed one thing: we did not have an end user.
Well, we had a client. A stakeholder. Someone with money to pay for our work. But there was no customer we could have given the solution we built to.
There was no way for us to actually verify our solution. This was the major problem we haven't fully realized the whole time.
Working truly agile
Working agile has more to it than doing daily stand-ups and retrospectives. One key aspect of being agile is to be able to react to change. Since agile usually also means that you don't have all requirements - including but not limited to what the end user wants - upfront, you need ways of defining those requirements towards the final result.
By yielding incremental results sprint after sprint, you have not only the chance to solve a big problem by solving smaller subsets of it but also to verify the solution.
Usually it is just not enough to check the result with your stakeholder, especially if it is the stakeholder alone. If there will be end users for the finished product you have to have end users for the product increments. Otherwise, you have no chance to verify what your team is doing.
With end users at your disposal, change can be introduced through gathered user feedback and key measurements. Verifying important aspects of your solution along the way increases the likelihood that your solution and your team will be truly powerful.
Reading Tip
If you buy something from the seller via the link above, I get a commission from your purchase. For you the price remains unchanged.
One comment