Conversation with Mike Griffiths

 

The Scrumptious blog is honored to welcome Mike Griffiths for a conversation about Scrum. Mike is one of the co-creators of DSDM and author of "PMI-ACP Exam Prep" which is the number one resource in my view for passing the PMI-ACP exam. It certainly helped me. Mike's full bio can be viewed at the end of this blog post.
 
1. Why do you believe Scrum is the most popular framework for delivering Agile projects?

I believe Scrum became popular because it is a clean, simple to understand approach. While it is difficult to master, the initial process is very easy to grasp. People are drawn to simple solutions. Like the Atkins diet that can be summarized as “Do not eat carbs”. When people are looking for guidance they want something they can quickly comprehend.

Personally, as a co-creator of DSDM, I was first a little envious of Scrum’s success. However, when you step back and realize that all agile approaches bring agile concepts to a wider audience, you can see the bigger picture benefits. Recently I have been impressed with the work of the Agnostic Agile community who seek to promote the benefits of agile separate from any specific approach.

2. In your book "PMI-ACP Exam Prep" you talk about both relative estimating and ideal time. There has been some confusion in the Scrum community about when to use story points and when to use ideal time for estimating and forecasting. Are there any circumstances in Scrum when estimating in hours and not points makes more sense?

For the PMI-ACP Exam we wanted people to know about estimation in both hours and in points. So, I cover both in my book. I see using points (or some other unit) as a next step in the evolution from estimation in hours. It avoids the artificial ceiling issue that can occur when a team has achieved its hours worth of work for the week.

3. One of the biggest problems with the implementation of Scrum is apathetic middle-management, even when Scrum has been sanctioned at the Executive level. Can you suggest ways for organizations to overcome this issue?

I rarely meet apathetic middle-management. I meet a lot of resistance in middle-management, but there is always a good reason for it. I suggest we work with them, find the cause of their misgivings, concerns or confusion. Maybe they do not understand, maybe there is a fear of loss (job security, status, role competency). Once we know why they seem to be resisting we can work with them to resolve it. Finding a way for them to get a gain rather than a loss out of transitioning to agile usually works well. Yes, traditional management roles are eroding, but there is a big demand for people who can straddle the agile to traditional space well. Perhaps by taking an active role in the transition as an enabler they can build valuable skills that increase their corporate value?

As such, I have never had long term conflict with middle management. Despite the stereotypes of them, most are smart, hard working people trying to do their best in a difficult situation that measures their performance using antiquated metrics. Spending time listening to their concerns usually helps uncover implementation risks that can be avoided before they become issues. They are a useful early warning system for implementation problem areas – engage them actively since they are well embedded in corporate culture and take their concerns seriously. Being prewarned of concerns can highlight the need for more information sessions and training. I’d rather tackle these misgivings proactively than when trying to get a project decision approved.

4. We all know Scrum is very well suited to IT and software development. How about non-tech domain such as construction and education? How can Scrum be applied to these and other non-tech domains?

Agile approaches, including Scrum work well for all knowledge work projects. These include teachers, lawyers, design engineers, marketing, etc - in fact any domain where subject matter experts come together to collaborate and solve novel problems. Environments where the bulk of the work is invisible and intangible (ideas, data, design) work well with agile approaches.

The steps of frequently reviewing increments of the solution are valuable to surface potential misunderstandings between contributors and sponsors. They also help assess the viability of the emerging product and encourage process improvement. Agile and lean have been applied very successfully to both construction and education as both the Lean Construction Institute and Agile In Education groups document.

5. Many of the benefits of Scrum are associated with reduced time to market which increases profits. How do you view the benefits of Scrum in the not-for-profit sector that isn't financially driven?

The terms you mention: “reduced time to market” and “increased profits” are proxies for Return On Investment and Value. Not-for-profits are typically even more focussed on ROI and value than for-profit organizations since they have to do more with less. Usually from modest income sources and donations they need to effect the maximum changes they were created for.

This is the perfect environment to apply agile’s lean inspired minimization of waste, value optimization, and continuous improvement models. Successful for-profit organizations can become fat, lazy, complacent and wasteful. They see what they are doing is working and fail to see the need to continuously improve, continuously cut waste. Instead they just want to scale up and crank their machine faster to produce more profits.

The not-for-profits I have worked with naturally took to agile approaches quickly. Their own principles on effecting positive change in the world fit with the agile mindset. Not for profits usually have a more socially aware culture that maps to agile’s mindset of empowerment and trust. If we use Frederic Laloux’s color framework, not-for-profits are Green and Teal organizations that fit well with Agile’s green culture and values. For these reasons and more I think agile approaches (including Scrum) are a great fit for not-for-profits.

6. What are the biggest flaws in the Scrum framework?

Ha, as an outsider to the Scrum community, I should be careful here. I respect Scrum and cannot argue with its success. If I had to think of some potential downsides I would say it sometimes appears to act as a walled garden. By this I mean changes are slow and funnelled through releases of the Scrum Guide. It also uses proprietary names of things to retain distinction and IP protection. Some of these names like Scrum Master raise eyebrows in conservative organizations. Other agile approaches have more professional, enterprise-friendly terminology, but none have Scrum’s market share.

Scrum’s simplicity is both a strength and a weakness – it is quick to grasp, but there is a lack of clarity on how to grow and scale. This has led to the proliferation of scaling approaches that appear confusing and sometimes contradictory to people new to the field.

7. In my Q&A with Ken Schwaber, I asked him should the Scrum Master role be renamed Scrum Coach to adhere more to a servant-leader model. He thought that would be a bad idea. Can you share your thoughts on this matter?

I will not try to guess Ken’s reasons for thinking this a bad idea. Personally, I think adopting a Scrum Coach title would have some advantages and disadvantages. On the plus side, it sounds more like a supporting, servant leadership role, as you suggest, that it should be. It is also not as pretentious as claiming to be a “master” of anything. That alone would go a long way to easing acceptance in many markets outside of the US.

On the downside, there is a championing role for agile concepts that some people may feel diminished with a “coach” title. Personally, I think we can only coach for positive change, trying to demand people never works long term. The cynical side of me wonders if the title “Scrum Coach” is too generic a term to be claimed under Scrum IP. It might already be public domain and seen as an erosion of the protected Scrum framework.

For my part, I don’t really care what we call people, if they are doing good work. As mentioned in Q1, the Agnostic Agile community wants to rid the world of proprietary names and instead spread the ideas as a free to use framework. That’s an idea I support more.

8. Your book suggests 12 members or less for an Agile development team, while the Scrum Guide advocates 9 or fewer. What is the ideal development team size and why?

I think it depends on the domain and what you are trying to build. For software projects, I have seen many very productive teams using 3 developers. 1 BA, 1 QA, and 1 SM for a total of 6 people – I do not think there is a magic number. Obviously, as team sizes grow, there are more communication channels to manage which takes more effort and increases the risk of miscommunication and confusion. So, I guess my recommendation would be as few as you need. 

9. What do you enjoy most about assisting organizations transition and succeed with Scrum?

It is great to see people ditch non-value adding work and focus on achieving results. Intuitively people want to do this but are often bound by corporate policies and frameworks that they do not have authority to change. Transitioning to agile approaches helps people see and take ownership of their actions. They get to work closer with the business and their customers. They experience the thrill and ownership of improving their own processes.

It is very satisfying to be a part, in small way, of increasing someone’s engagement and happiness at work. It is them making the change and getting the results, but if I played a part, it is a good day.

10. Where do you see Scrum 5 years from now?

Ideally dead and buried. It would be great if Scrum and all the agile approaches were just wrapped into a better commonly accepted framework for collaborative development. Or replaced completely by something better. However, we have been saying this for over 10 years and it has still not happened, so I expect it will still exist.

It’s ironic that agile was once the new rebellious upstart to replace the corporate mandated processes. Now, for many people entering the workforce it is the established, mandated process. I am hopeful that people will once again rise to replace it with something better. Staying the same is a recipe for stagnation and decline. Change can be evolutionary or revolutionary. Evolutionary change is usually small, slow, controlled and generally successful. Revolutions are big, messy, risky and exciting/alarming depending on which side you are on and if it is successful or not.

                                                              ***

Mike Griffiths is one of the co-creators of DSDM. He served on the board of the Agile Alliance and the Agile Leadership Network. He remains active in the agile community and takes the agile message to those that need it the most – old-school project managers. Seeing the biggest resistance to agile values in command-and-control management, Mike tries to influence project management from inside the PMI. He helped create the PMI-ACP credential – an approach agnostic certification. He was recently chair of the Agile Practice Guide, a joint publication by the Agile Alliance and the PMI. Mike lives in Canmore, Alberta and maintains the blog Leading Answers at www.LeadingAnswers.com.
 

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!