This week I dived into two books that are both 100 pages give or take. Both are fairly easy to get through and are worthy of bookshelf space. My purpose of reading these was to get a better understanding of two practices of applying Agile principles. I am an agile rookie who wants to understand/learn about ideas and practices that I could add to my toolkit.
Agile Software Development With Scrum
This was an easy read especially with it’s case study focus to illustrate the idea or practice. I felt the “spirit” of agile in the principles and found the practices shown in scrum enlightening.
I gained a deeper understanding of the how the scrum master facilitates and leads only. I found it intriguing that the scrum master does not make decisions. The master is there to coach the team and even though I understood this I didn’t connect the empowerment of the team with the master not making the decisions (A duh moment). It makes sense that if you want to empower the team to make decisions then you have to give them the power to decide. I could see the old school mentality in my original thought process.
The sprint is sacred. Nothing can/should eek it's way in. This is a big key in ensuring the team stays focused and on task (or should I say feature). If necessary a sprint can be killed if important enough and restarted with new focus.
The team’s daily stand up are for each other and no one else; not the scrum master, product owner, etc. A particular story caught my attention on this. The developers when giving their report were looking at and talking to the scrum master directly. The meeting degenerated into a project / task status update where the team viewed the scrum master as a classic project manager. A real test of a good stand up is the team should be looking and talking to each other because they are responsible to each other. The scrum master is there to observe and if they see something that could use some coaching they should remain silent and look to mentor sometime after but not during the stand up.
Project management is featured based not task based. Real success is not based on the adherence to a project plan. It’s based on the delivery of the right features with the right functionality that the customer needs. That doesn’t mean project management or a plan is thrown out the window.
For anyone trained old school this could be a hard transition and the case studies do a good job of illustrating people who hang on to their old ways and how to remedy the situation.
Lean Software Development
Eliminate waste does not mean throw away all documentation.
Amplify learning does not mean keep on changing your mind.
Decide as late as possible does not mean procrastinate.
Deliver as fast as possible does not mean rush and do sloppy work.
Empower the team does not mean abandon leadership.
Build integrity in does not mean big, upfront design.
See the whole does not mean ignore the details.
These are statements directly from the book. I can’t think of a better way to summarize this book. Lean strikes me as less prescriptive in it’s practices than Scrum although I could be wrong on that. Like the agile manifesto, it gives me guiding principles but at a lower level that one can use to help create practices.
Both books are an excellent read even if you aren’t interested in applying them. I can’t see how you won’t come away with a least something to consider for yourself or your team.
If you are interested in applying these practices both books stressed technical practices as a must. Lean Software Development had very good advice to get started:
Start with hygiene. First of all, make sure that you have basic professional software development practices in place: a version-controlled code repository, coding standards, build automation, comprehensive testing, etc.
A major key to Scrum and/or Lean or any other agile practice is the need for good technical practices. If you only use Scrum/Lean as yet another project management methodology you are in trouble.
Above all, each team/environment must adapt for their situation. These are guiding principles and practices that need real world applied to them.
As a newbie to agile I am sure I have not understood everything right or deeply enough. Please let me know what you think. I like to learn from others!