The goal is not to use Scrum or Lean. The goal is to be agile and to experience the benefits of both running product development projects with agility and running a company with agility. We must know our strengths and weaknesses as an organization and face the challenges to becoming agile. An Agile transformation is not easy. Adopting Agile software development techniques does not solve problems, it exposes them. Let's take a quick look at the Agile Manifesto for a refresher.
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
I will write a blog on each of the four principles to talk about the ramifications of each in the context of an Agile transformation. Today I want to encourage you to not get the process backwards. Adopting Scrum for a project within an organization that is not agile isn't a terrible way to start learning about Agile software development, but be warned. It is almost impossible to be Agile on one project in isolation. Agility is about collaboration, communications, rapid change, and quickly releasing software. It is really hard to do those things within an organization that does not yet support or has not yet adopted Agile practices. You will run into resistance from business folks, Finance, PMO and other stake holders because they don't understand what you are doing and why.
In my last blog post, Agility - using all your senses, I pointed out that you need to measure agility across 5 areas: externally, internally, financial, operational, and people. When you do a single project using Scrum, the only pieces you are touching are the internal and the people directly involved in your project. I'm not saying you should never start an Agile initiative by introducing Scrum or another Agile approach for software development. What I am saying is, understand the challenges you are going to face organizationally. You may want to release software quickly with a very short development cycle, but the PMO, QA, and Operations may oppose you because they have policies, processes and procedures that prohibit releasing software without their blessing and sign off.
I'll give you a specific example from a project I worked on from 2015 into 2016. We embarked on a mobile software development project using a Scrum approach within an organization that had never done Agile software development before. This was a contracted services arrangement where the client hired us to come in and develop the software and specifically requested that we introduce Agile practices. We ran into a QA department that was completely unwilling to adopt an Agile approach. They insisted that they would wait to review the software until we got to a major milestone. Only then would they do full end-to-end testing, and show the software to actual users. They also demanded comprehensive design documentation and insisted that any feature or functionality that was not supported by comprehensive documentation would not be accepted.
As you can imagine, this project became waterfall by Sprints, not Agile using Scrum. Senior leadership was unwilling to change their QA processes and we were completely blocked from doing usability testing until about 9 months into development. Of course, the project was not highly successful and the organization is now going through fairly dramatic changes. The actual Agile transformation as begun. So, my warning about trying to initiate Agile software development with a single project comes from experience. That said, sometimes you have to expose the problems with a failed project in order to wake folks up and force hard conversations. That organization will be much more successful on future projects because of what they learned over the past year and their new willingness to change.
No comments:
Post a Comment