“Process” is a word that seems to have a lot of baggage. Depending on whom you ask, process is either essential to delivering value, or something that gets in the way. But this is the wrong way to frame the issue. A process is not inherently good or bad; it's how you use it, and whether it's right for your situation.
Steve Berczuk is a Principal Software Engineer with experience as a manager, Scrum Master and technical lead in Boston, MA. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a Certified ScrumMaster. Contact Steve at [email protected] or visit berczuk.com and follow his blog at blog.berczuk.com.
All Stories by Steve Berczuk
The Scrum Guide specifies that there are three roles: product owner, developer, and ScrumMaster. It’s essential that a Scrum team have each of these roles to help it work well. But depending on how you implement the roles, you may end up hurting rather than helping your Scrum process. Focus on goals, not job titles.
Regular one-on-one meetings between a manager and employee are a forum to provide safe, timely feedback. They can be short or longer, but you should discuss successes, challenges, and how to improve. Having a framework for the conversation helps you make sure that the meetings don’t routinely become chat sessions.
A defined, repeatable process frees people from spending energy thinking about solved problems, and an automated one makes this even easier. While not all development steps can be easily automated, some can, and documentation is an essential first step. Automate what makes sense and you'll have reliable processes.
Some teams get around bottlenecks by taking a “better to ask forgiveness than permission” approach. This may be expedient, but it doesn’t provide a path to changing the organizational dynamic, and it can lead to wrong decisions when wider input is advisable. A more agile way is to take an “I intend to” approach.
When things go wrong, it can be helpful to understand what happened and who was involved. However, all too often organizations (and the managers within) confuse responsibility with assigning blame. The former is essential for improvement. The latter works against an effective, collaborative, productive culture.
Building good habits is an important part of an effective Scrum team. Habits are a form of automation: The more basic processes we can automate, the more we can focus our energy on hard things. The Scrum process, with its focus on rituals, helps us by providing a framework for collaboration and making it second nature.