Agile Project Management with Scrum by Ken Schwaber

Agile Project Management with Scrum (Microsoft Professional) is a well written, easy flowing book that is clearly borne from someone whose had first-hand, real-world experiences of running and managing a variety of Software Projects over a number of years, Ken Schwaber, who is considered the father of Scrum who humbly takes no responsibility for being assigned that title, and so points to much earlier endeavours of many people, pointing to Babatunde's Process Dynamics, Modeling & Control for his first oral presentation of the theory behind Scrum; and sites Degrace's Wicked Problems, Righteous Solutions as the first people to call Scrum Scrum.

Regardless of who is attributed to formalising the Scrum processes, it is a software development methodology that is here to stay, and anyone working in software projects not familiar with Scrum should indeed rethink their strategy. Still, with so many books out there claiming to distil the secrets of Agile/Scrum, finding the right book is indeed challenging -- as with so many books, people focus on the theory without expounding on the practice, the real-world experiences and encounters that as a manager, and especially as someone transitioning from classic project management principles (not necessarily connected to the Watefall process of software development).

This book is definitely different, one that I recommend and fully endorse 100% - so if you're reading this and don't have a copy, get one now!

Why do I like this book so much?

Well, as a developer I'd worked on many projects of different styles, more recently explored with Agile/XP concepts. I've been on training courses, presentations & and participated in practical workshops such as the agile lego game. I've contributed as a developer, lead certain development efforts with a few engineers, then later went on to managing development projects using Waterfall as well as Agile; and more recently came off a massive project with 300+ people, where at the macro-level applied Agile/Scrum principles across the programme, but I didn't have much involvement in the day-to-day planning with individual component teams, where we'd assigned team leaders to act as Scrum Masters. We maintained one huge Product Backlog, not so different to that as Ken describes in Chapter 9 Scaling Projects Using Scrum.  We were developing a product that would deliver to multiple customers, each customer adding unique features contributing to the final feature set, the product itself would service tens of millions of homes -- so we had a strong Product Management group maintaining the heartbeat of the multiple projects using Sprint Time-boxing. We had macro daily planning and status updates, call it Scrum of Scrums.  So I was pretty much focussed on the high level programme and product management, than the low-level activities that a Scrum Master would normally be dealing with, I'd instruct as necessary....

As I was moving to a new job that placed me in a Scrum Master role, I needed to brush up on my Scrum Master knowledge and needed to prepare or translate my heavy Project Management experiences to Scrum principles. This book was certainly written with that purpose in mind. I was looking for real world use cases and reflections of actual projects, something that Ken describes well.

Ken touches on the key concepts of Scrum by using example projects as references, with frank and honest feedback. He includes much of the areas that would trip someone up coming in cold to Agile, and also does not dismiss the value and usefulness of applying the rigour of classic project management dogma (reporting, tracking, metrics, predictions) as old-school, out-with-the-old, in-with-the-new.  In fact, Ken advocates entirely the opposite of that. It certainly takes a while to master Scrum as a Scrum Master, and therefore takes much longer for a company with seasoned managers who know no better, to transition and accept Scrum from day one.  So as important stakeholders in the project and business, these people have a right to be given information in a format that is understandable, and this too, can still be achieved using Scrum.

What really resonated with me was...

Ken has re-affirmed much of my own understanding in that Agile/Scrum is no excuse to cut corners. Scrum is not a short-cut from applying rigour and due diligence.  Way too often, people who are either new to Scrum or have been previously burned by management, fall in love with the concepts of Scrum, especially the tenets of autonomy, freedom and do-what-it-takes attitude to get the job done, immediately put up barriers when someone starts talking about processes...

• "Oh that's waterfall approach, we are young developers, we don't do it like that anymore. We are light on process, and don't need documentation. We don't need to have a process for teaching new engineers, it's a collective, the engineer will be absorbed into the team and learn on the job. We don't have release notes any more, it's automated by Git. We don't need a version numbering system, Git labels are fine. We don't do need pre-planning, we do just enough because it's going to change anyway...."

Principles I connected with...

• The importance of taking time out to produce a Product Backlog early in the project. The argument of not knowing what you're creating because it's unknown is not good enough. Even if you're aiming to brainstorm to produce an initial Proof-of-Concept (POC), that POC is driven by meeting the high level needs of the Product Owner, so it is not an impossible activity to put thoughts onto paper, call it your wishlist, to-do list, whatever - there must be a Product Backlog to start with...how else do you determine the goals, and measure your progress accordingly??  So if you think you're doing Scrum and don't have a Product Backlog, then please go back and reconsider what you're doing...

• Ensuring the Roles/Responsibilities are clearly identified - especially the ownership of the Product Backlog - Is your project big enough to have its own Product Owner, or is this also something the Scrum Master can absorb?? The Product Owner's role is pivotal to setting feature priorities only, but not responsible for driving through scheduling or people management. That is the Scrum Master's job...So spend time to clearly outline the roles and responsibilities...

• Spend enough time Planning - the planning process described by Ken is a useful starting point. Spending a full day on planning and getting the team to uncover the tasks before the Sprint begins is definitely valuable.

• Due diligence must be followed by Scrum Master - measuring progress and reporting on progress, generating metrics and predicting the future are essential aspects to Scrum Management.  Don't be fooled by Scrum being lighter than classic project management. Scrum teams still have a responsibility to meet business objectives, how you go about doing it is the Scrum teams own business, but when asked with business-type questions, then the Scrum team better have enough data to provide professional responses

• Don't misuse Waterfall defence mechanisms - who says you don't do requirements/design/testing - Scrum says you ensure enough is done during the sprint such that at the end of the Sprint you produce a release that is shippable - so a Sprint must support requirements/design/testing/validation/release - same steps as waterfall, but it's constrained to happen within the sprint itself. Of course, one doesn't have to have heavy processes, but it is about applying core engineering principles.

• Self-organising teams are difficult to create, and takes time to master.  As a Scrum Master you have to continuously monitor the team's performance and interactions.  The hard truth is that in the real world, using distributed development or even multicultural teams with mixed permanent/contractor staff, a truly self-organising team is a rare find.

• Common sense - a large part of Scrum is essentially maintaining a common sense and pragmatic approach to things.  One doesn't have to be a certified Scrum Master to manage Scrum projects, but care should be taken in obeying & applying the rules of Scrum, which Ken concludes in Appendix A:
• The ScrumMaster is responsible for ensuring that everyone related to a project, whether chickens or pigs, follows the rules of Scrum.  These rules hold the Scrum process together so that everyone knows how to play. If the rules aren't enforced, people waste time figuring out what to  do.  If the rules are disputed, time is lost while everyone watis for a resolution. These rules have worked in literally thousands of successful projects. If someone wants to change the rules, use the Sprint retrospective meeting as a forum for discussion. Rule changes should originate from the Team, not management.  Rule changes should be entertained if and only if the Scrum Master is convinced that the Team and everyone involved understands how Scrum works in enough depth that they will be skillful and mindful in changing the rules. No rules can be changed until the Scrum Master has determined that this state has been reached.

Watch the man himself here @ GoogleTechTalks: