Agile Principles Shine Light on Development Projects

I settled into the visitor’s chair across the desk from Nate. Looking at Nate I said “So tell me about your project.”

RULE II: START WHERE THE SYSTEM IS1

Nate smiled and wistfully said: “Well, I’m the project manager and ScrumMaster. John will be the Product Owner. He works in our North East office. He should be able to represent the user community. He used to work in it. The tech lead and development team work in Europe.” Pausing he continued, “From what I’ve read, the Pundits suggest we’re doing almost everything wrong. But it’s the reality I’m forced to deal with.”

“So Nate, what do you know about the Agile Manifesto?” I asked. “Oh, the ‘We value Individuals and interactions over processes and tools’ stuff?” Nate replied. “Absolutely, but have you ever clicked on the twelve principals link? No? Let’s take a look at them and see what might apply and help you with your project.”

Like me, the clients I work with want to improve their effectiveness. When I visit clients I’m aware that with respect to their system, I’m both spatially and temporally blind.2 I don’t know what has happened with the people and organization prior to my arrival (temporal blindness). The information I do gather usually represents at most a handful of viewpoints on what’s happening (spatial blindness).

Is a radical new start, a revolution the best way to achieve effectiveness? Or would changing just a little now, some more soon, evolving toward the final goal be a better approach? The best answer I have today is, “It all depends.” Nate works in a multinational conglomerate. Revolution will be stomped out faster than the speed of light. But evolution, starting where they are, inspecting and adapting has a chance to work.

We spent the next day and a half working through the twelve principles and how Nate could implement them in his project.

  • We started reworking the software architecture list into user stories.
  • We talked about Done, Done, Done. We reviewed the various types of testing and how/when to do them.
  • Nate planned to have two week sprints. In addition to this, he’s now planning to have an automatic push to the test environment after every sprint.
  • Potential system users will interaction with the code in the test environment and provide feedback to the product owner.
  • We discussed metrics for the sprints and how he could use velocity to gauge project progress for the releases.
  • How to conduct the five Scrum ceremonies.

In the end, the major hurdle remains the team’s distributed nature. Otherwise, Nate’s project embraces the agile principles.

As I was leaving Nate said, “Yes, I know it’s not ideal agile. But it’s where we are. In time, we hope to build on our successes and eventually change how IT projects get identified, defined and funded.”

The flame flickers and light shines.

What’s your experience? Revolution or evolution? Send me an email.

1Herbert Shepard, Rules of Thumb for Change Agents, 1974 http://www.nickheap.co.uk/articles.asp?art_id=257

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *