Thursday, April 2, 2009
The Art of Software Development
My company and our consultants have been using Scrum and Agile techniques on both internal and client projects for years. Our adoption has been in an ad-hoc manner and often times behind the scenes without anyone knowing that's what we were doing. Things just got done. I have had the pleasure of taking 2 days to formally learn the Scrum framework and become a certified scrum master. I am using the training to pull all the techniques together and gain a better understanding of how to best use the Scrum theory of delivery with my client projects. During the training I had an "AH HA" moment (as Oprah puts it) - software/product development is an art NOT a science! The principles of scrum center on communication, collaboration, and using a feedback loop with stakeholders to produce a quality product in a short period of time. Notice I didn't mention anything about stages, gates, documentation, or sign-off. Not that a paper trail can't be produced along the way but Scrum is more about focusing team energy on getting a usable product out the door than hashing through getting the right requirements in a document. With Waterfall there is a certain amount of risk mitigation built into the formality of the sign-off process. If the requirements are written down and stakeholders sign-off, the risk of not getting requirements right shifts from the development team to the stakeholders. From the development team's perspective "They (the stakeholders) told us what they wanted and here's the proof". In Scrum people collaborate and come up with the requirements together. The stakeholders provide some high-level product requirements/priorities to set the direction and the team uses demos and stakeholder feedback to make sure they get it right. It's so simple and uncomplicated! The Scrum Master is really more team psychologist than Project Manager. Tasked with enabling each individual team member to speak his mind and foster a sense of shared ownership to complete the team's goal. Not pouring over the Help documentation in MS Project to figure out how to do resource leveling. Team members and stakeholders (via the Product Owner) get to communicate directly instead of through the formality of requirements documents and change requests. Imagine what is possible when everyone is collaborating and developing solutions together. All the innovation that the different perspectives can bring! I'll admit, I may be a little drunk on the Scrum kool-aid right now, but what were thinking taking the human element out of software development and communicating through documentation that quickly gets outdated?
Subscribe to:
Post Comments (Atom)
3 comments:
Kelly -
Excellent summary of Scrum. I think we've all used this method at one time or another, often with different names or conpamy mantras attached. Nice to know "organized chaos" has a better-sounding name!
The one major drawback I have seen with SCRUM is the requirements definition. I know it's not as hard and fast as traditional waterfall but a team can easily get lost, running in circles, if direction or expectations are defined well enough at the start. Progressive elaboration is key - often and as detailed as possible - to make sure team direction does not wander.
Can you share any documents, presenttaions, or links for the training you attended?
Jerry Matthew
Jerry -
You bring up a valid point about staying focused on requirements. Making sure the "Product Backlog" has been thought through at the right level and documented appropriately is important. One tactic our teams have used is creating simple process flows for how new functionality should behave at a high level. This gives the development team a running start with some high level guidelines for building new functionality while not choking the creative process by dictacting exactly how it should look or work. Thanks for your comments!
Jerry-
The way to address your concern in Scrum is through Product Backlog grooming. This would be a certain amount of time spent, during each sprint, reviewing and editing the Product Backlog, adding or deleting stories or epics, and performing high-level effort estimation for the backlog stories. The meeting is attended by the team, the Scrum master, AND the Product Owner. All work together collaboratively on editing the backlog. This meeting should happen each sprint, and according to Scrum founder Ken Schwaber, should be no more than 5% of the working time of a sprint. For a 3-week sprint of 7.5 hour work days, that comes out to a meeting of a little more than 5.5 hours. That might be extreme, but while it's not one of the official prescribed meetings of Scrum, it's critically important to making sure the team and Product Owner remain on the same page, and the Product Backlog items remain current and relevant.
Post a Comment