Look Forward Consulting » Team

SoCal Code Camp Fullerton

Carlton — Sat, 29 Jan 2011 15:55:01 +0000

It is time for Code Camp in Fullerton this weekend. I will be speaking on Saturday on this two topics.

Scrum Roles in Action: in Scrum, there are three basic roles – Team member, Product Owner and ScrumMaster. Each role is defined with some basic specific rights and responsibilities and filling in the rest of what one is supposed to do is left as an exercise for the participants. In this workshop, we will review the rights and responsibilities for the Scrum three roles (plus stakeholders) and discuss what those roles look like when preformed well.
ScrumMaster Toolkit: are you just getting OK results with Scrum? Has Scrum not delivered on the much anticipated quantum leads in productivity everyone had been promised? One common source of lackluster performance comes from following routine behaviors and ordinary patterns of teamwork associated with the “old way of doing things”. In this hands-on workshop, Carlton Nettleton will share powerful techniques from his coaching toolbox that breaks these old patterns, unlocks the potential of Teams and gets them moving toward high-performance.

Scrum Bill of Rights

Carlton — Mon, 24 Jan 2011 18:27:27 +0000

One of the things I admired about Extreme Programming (XP) was the simplicity of the roles defined in the Green Book. In XP, there are only two roles: Customer and Programmer. When you are using XP, the Customer makes business decisions, Programmers make technical decisions and one role may not substitute their judgement for the other. In short, Programmers do not make business decisions and Customers do not make technical decisions. Kent Beck and Martin Fowler even went so far to add a Bill of Rights, which clarifies what people can expect for one another.

Scrum does not have anything similar, so I decided to create my own (modeled on the XP rights). Feel free to distribute and share.

Every Team member has the following rights:

To produce quality work at all times.
To know what is needed from the business with clear declarations of priority.
To ask for, and receive, help from peers, management, and customers.
To experiment with new ideas, technologies and roles to grow both as a professional and an individual.

Every Product Owner has the following rights:

To receive the greatest possible value out of every week.
To know what can be accomplished by the Team, when and at what cost.
To see incremental progress in a viable product proven to work by passing acceptance criteria they specify.
To be informed of schedule changes promptly in order to take effective countermeasures and reset expectations with the stakeholders.
To collaborate with the business on setting the future direction of the product.

Every ScrumMaster has the following rights:

To try out different ideas, approaches and techniques to remove impediments which impede the flow of value.
To be given time for initiatives to take hold and produce change.
To take measured risks and learn from setbacks.
To be supported by senior leaders in the organization.
To be provided access to different parts of the business while identifying and removing impediments.

Every Stakeholder has the following rights:

To receive regular status updates through interacting with a working product.
To change their mind, substitute functionality, and adjust priorities without paying exorbitant costs.
To cancel the product at any time and be left with a working product providing real business value reflecting the investment to date.

Scrum Roles Defined

Carlton — Fri, 21 Jan 2011 16:52:00 +0000

I do a lot of work with Scrum and the ones that struggle the most are the ones where the Scrum roles are poorly defined and\or not filled properly. Scrum is a balanced framework and when the roles get muddled, the framework begins to adopt the dysfunctions of the organization and is not as powerful as it could be.

In Scrum there are three roles – Team member, Product Owner and ScrumMaster. Those three working together are called the Scrum Team (or just the Team). I add a fourth role – Stakeholder – to recognize all the people who orbit a Scrum Team and influence them. I define all these roles like this:

Team: dedicated collection of self-organizing, interdependent, co-located individuals representing different functional roles with all the necessary skills to turn Product Backlog items into a potentially shippable increment within the Sprint.
Product Owner: an empowered individual applying their personal and professional judgment to make decisions in the best interest of different,often times competing, business stakeholders to maximize the business value the Team produces each Sprint
ScrumMaster: a dedicated individual responsible for improving the performance of the Team and the business by any means necessary.
Stakeholder: any person who has a direct, or indirect, interest in the work of the Team.

Keep in mind, these are role definition, not job descriptions and they are very loosely defined. It is important that each role is filled. In general, the Product Owner is concentrated on the providing valuable business outcomes to the business, while ScrumMaster is aiming his\her efforts at the execution of good Scrum and improving the flow of value to the customer. Meanwhile, the Team remains centered on learning how to self-organize and deliver potentially shippable increments regularly. Stakeholders provide feedback on the value of everyone’s efforts.

When Scrum falters, it is often because people are not committing to their roles. Other times, organizations chose to overload one, or more, roles in a single person, disrupting the balance of the roles. Recall, the Scrum framework was designed to provide the maximum amount of flexibility with the minimum amount of control. If these roles cannot be filled with individuals who will fully inhabit them, or they are overload, the control mechanisms of Scrum become unhinged, visibility is diminished, accountability is lost and the framework loses its meaning.

When Scrum is done well, there exists a natural tension between each role. This tension exerts a force that tends to prevent the other roles from meddling in responsibilities that are not their own. Since there are considerable gray areas on the role boundaries in Scrum, each role will eventually bump into one another as they discover what are the boundaries of their responsibilities. This friction is an essential part of learning how to do Scrum and making it meaningful to your business. Through the of process of inspect-and-adapt, the precise definition of each role – Team member, Product Owner, ScrumMaster and stakeholder – emerges as your organization gains experience using Scrum.

One of the main reasons why I add a Stakeholder role to Scrum is because many Scrum implementations improperly keep these people out of the process. Scrum was not designed to keep the Stakeholders from interacting with the Team. In fact, Scrum was designed to bring these folks closer together. What Scrum tries to do is give the Stakeholders a more meaningful, structured way to interact and provide the Team with feedback via the Sprint Review. This is the opportunity for the Team to hear direct, unvarnished feedback on what they really think. This is why Stakeholders have a dashed line connecting themselves with the Team, rather than a solid line.

Speaking @ Agile San Diego on Oct 7th

Carlton — Thu, 30 Sep 2010 00:52:17 +0000

Next week I will be speaking at one of my favorite groups – Agile San Diego – on October 7th beginning at 6:30 PM. The topic will be “Tools for ScrumMasters and Agile Team Leaders” and this is a quick description of the session.

Are you just getting OK results with Scrum? Has Agile not delivered on the much anticipated quantum leads in productivity everyone had been promised? One common source of lackluster performance comes from following routine behaviors and ordinary patterns of teamwork associated with the “old way of doing things”. In this hands-on workshop, Carlton Nettleton will share powerful techniques from his coaching toolbox that breaks these old patterns, unlocks the potential of Teams and gets them moving toward high-performance.

This is going to be a fun evening and a bit experimental since I am going to leave the main learning objective up to the participants. I will also be giving away a free copy of Lyssa Adkins’s excellent book, Coaching Agile Teams. Come to The Linkery, have a few drinks and learn something new!

Speaking @ Agile San Diego on Oct 7th

Carlton — Thu, 09 Sep 2010 17:03:10 +0000

I will be running a short workshop at the next Agile San Diego meeting showing off a few of my favorite coaching tools. If you are looking for a few new tricks, stop by and say hello.

Are you just getting OK results with Scrum? Has Agile not delivered on the much anticipated quantum leads in productivity everyone had been promised? One common source of lackluster performance comes from following routine behaviors and ordinary patterns of teamwork associated with the “old way of doing things”. In this hands-on workshop, Carlton Nettleton will share powerful techniques from his coaching toolbox that breaks these old patterns, unlocks the potential of Teams and gets them moving toward high-performance.

Reading List (1st Half of 2010)

Carlton — Mon, 23 Aug 2010 16:56:23 +0000

Wow! I have read a LOT in the last six months! I guess that is one of the advantages of being on the road for about six months.

Understanding A3 Thinking – excellent description of how to use and create an A3: a Lean tool for executing Plan-Do-Check-Act (the Deming cycle). This is the definitive source on A3, Henrik Kniberg has an Agile example and template on his site.
Getting the Right Things Done – good description of the concept of True North, developing strategy from True North and the respectful nature of Lean, the rest is kinda dull.
Pedagogy of the Oppressed – unique perspective on the characteristics of oppression, the oppressed and the oppressors; liberation for both the oppressed and the oppressors originates when the oppressed become fully engaged in the human dialogue of being, not simply exchanging roles with the oppressors. Interesting connections to corporate life in the 21st century.
Project Retrospectives – discussion on the importance of making a deep-dive examination of a software project when it finally is complete with detailed exercises and agenda. This is great book if you want to know more about retrospectives.
More Secrets of Consulting – just brilliant! If you liked the first book, this one has so many practical gems for the consultant. The only tedious parts of this book are the references to his other books. My favorite tool: the Wishing Wand.
The Future of Management – this book was a favorite of the CEO at my last client. There are many Scrum concepts in the case studies provided. Too bad that many of the principles of self-organization and empowerment supported by the executives never filtered down to the teams
Coaching Agile Teams – WOW! This is an awesome book, deep and rich with many profound insights on the various roles of an Agile coach. In addition, Lyssa provides practical tools to improve both the coach and the individual. This is definitely a book to return to again and again.
Training From the Back of the Room – this is my favorite book from the last six months since it has had the most impact on my personal performance. It has changed my perspective on how to train adults with its sound theory of education and myriad of exercises which bolster learning. Share this book with anyone who trains adults (thanks to “Agile Bob” Hartman for tweeting this book title!)
Practices for Scaling Lean & Agile Development – comprehensive companion book to Scaling Lean & Agile Development (which is very good on Lean and Scrum). This book is full of good stuff, but just too long. Unless you are a guru (or wanna be), stick with the first book.
Succeeding with Agile – Mike Cohn has put out another great book based on his years of practical experience with Scrum. This book is also pretty long, but not tedious. A great read if you have some experience with Scrum, but want to improve the overall experience, apply targeted improvements or figure out how to expand the reach of Scrum in your organization – it covers it all.
The Back of the Napkin – provides a framework on how to apply visual thinking tools to explain and sell ideas. Since most of the work I do is conceptual, being able to draw a powerful picture is a useful skill. A nice addition to my consultant toolkit and I look forward to sharing it with others (I didn’t find the companion book that useful, so skip it).
Hitchhiker’s Guide to the Galaxy series (not pictured) – these books were consistently entertaining, surreal and light; most were less than 200 pages. The pace slows down around book 3 (Life, the Universe and Everything), but delightful nonetheless. I cannot believe I just discovered them in my mid-30′s!

Believe it or not, there are a few books I did not get a chance to read. I guess these will have to wait until after vacation.

Leading Out Loud – about finding your authentic voice in business. I bought this to get some ideas about leadership and self-organizing teams.
Hope is Not a Strategy – I need to understand the sales process better and improve my ability to sell. This looked interesting.

You Can’t Phone It In

Carlton — Fri, 20 Aug 2010 03:24:06 +0000

Being a ScrumMaster is much more than just showing up for the Scrum meetings and lobbing in a few facilitation techniques to keep things moving along. Yet I think many project managers who are new to being ScrumMasters misunderstand what is required of them. I feel they read about Scrum in one of the many excellent books on the topic and think, “Facilitation…four meetings…lessons learned…planning…task tracking. OK, that looks easy – I can do that in my sleep.” All they can see are the transactional aspects of Scrum. Since that is all what Scrum is to them, they bring the empty project management mindset to the work and the result is a functional Scrum without any purpose, rituals without any meaning. And this is where I think many project managers turned ScrumMaster stumble with the role.

An excellent ScrumMaster has a real presence with the Team. To become an excellent ScrumMaster one must go beyond the simple transactional elements of Scrum and focus on the transformative aspects of the work. As ScrumMaster you need to focus, really focus, on the needs of both the Team and the individuals as you work to improve the environment they work in. You need to be both physically and emotionally there for them in a profound way.

Scrum’s great promise is that it reconnects people to each other work through empowerment and true collaboration. As ScrumMaster it is your responsibility to facilitate collaboration, to help people feel comfortable and willing to take both professional and personal risks. This does not happen in a fifteen minute Daily Scrum, or a two-hour Sprint Planning meeting or during a Sprint Retrospective. Those rituals have very specific goals and individual coaching is not one of them. The moments where one-on-one coaching happens and trust is developed are the times when the people are doing the work. It is those moments when one notices a Team member’s joy, disappointment, frustration, happiness and anxiety. You catch them being real and experience the moment with them. This only happens when you share physical proximity, observe and be present when these moments happen.

In Scrum, we strive to give the Team members slack and ask them to limit multitasking to preserve their focus. We expect the same from the ScrumMaster and that is why I recommend new ScrumMasters only focus on one Team. If as a ScrumMaster you are lurching from fire-to-fire, meeting-to-meeting, team-to-team you are still operating in the old project management paradigm and it needs to stop. People on the Teams need your help. Stop being so busy and focus on what the Team needs for a change.

Best Links of the Week – July 30th 2010

Carlton — Fri, 30 Jul 2010 16:15:22 +0000

More great writings gathered from far and wide.

Scrum at Mind Candy – brief video of a task board in action over a three month period.
Confessions of an Agile Project Manager – PMI sponsored a video contest among PMP using Agile – check out the results on YouTube!
Thoughts on two months pairing - Sarah Mei reflects on her experience pair programming and the benefits it has provided her professional & personal life.
Can Agile Learn Anything from PMBOK? - Dennis Stevens looks at how the PMBOK supports, compliments and impedes Agile and proposes some solutions to make the two synchronize better.
Multitasking Gets You There Later - Roger Brown discusses a common paradigm in project management when dealing with too many projects and too few people.
Waterfall, Lean\Kanban and Scrum – Ken Schwaber, co-creator of Scrum, discusses why Scrum relies on empirical process control theory and why they did not choose Lean or a defined process.
The Role of Middle Management in Toyota or a Lean System – special post on the new focus of management in Agile organizations.
Team Room – want to get increased focus, quality and retention from your Team? Check out this team room article by Martin Fowler.
Agile + UX: six strategies for more agile user experience – how Comcast is combining good user experience (UX) practices with Scrum.
June 2010 CSM class – very cool visualization of a Certified ScrumMaster class taught by Tobias Mayer and Bachan Anand.

Best Links of the Week – July 16th 2010

Carlton — Fri, 16 Jul 2010 20:51:28 +0000

Passing on some good summer reading.

Core of Agile and Scrum – essential principles of Agile and Scrum that transcend the software development.
Three Legs to an Agile Transition – George Dinwiddie looks at how teamwork, visible progress and continuous improvement are key to change organizational culture.
Why Multiple Product Owners is a Bad Idea – read the article to find out how having multiple people setting priorities short circuits the role.
Nobody Can Do Agile – Simon Bennett explains why Agile is about thinking, not doing.
Agile Requires Cross-Functional Teams – Johanna Rothman discusses why cross-functional teams are essential for Scrum and other Agile processes.
Sir, Please Step Away From the Team – common the changes in management style for managers when Agile teams start in your organization.
Story Time! The hidden Scrum meeting – ever wonder when the requirements and the analysis happens on a Scrum Team?
How Does a PM and SM Coexisit? – a reader asks Michelle Sliger how the role of the project manager changes with the introduction of ScrumMasters.
Truly Agile CMMI – a short blog and video about a company that gets both Agile and CMMI.
Millennials and Scrum, Made for Each Other – Lyssa Adkins talks about how the Scrum values and principles align with a new cohort entering the workforce.

Best Links of the Week – July 2nd 2010

Carlton — Fri, 02 Jul 2010 18:22:38 +0000

New stuff to read and learn before the holiday

The Zen of Scrum – Jurgen Appelo provides a 70-minute video overview of Scrum, roles and philosophy.
The Difference Between Waterfall, Iterative Waterfall, Scrum & Lean (in pictures) – Visual representations of these various processes.
Company Culture Affects Your Code – A short examination of influence of Conway’s Law and culture on your software projects.
Explosion of Agile Practices – A list of 50 or so common practices used on Agile teams.
My Progression Toward Kanban – Brian Doll provides a good overview of Lean software development techniques and his personal journey there.
Post Agile Companies – Cory Foy looks at three Agile organizations and explains why understanding the Agile principles and values is more important than doing the Agile practices.
How Great Leaders Inspire Action – Simon Sinek describes a simple model to inspire others in this 18-minute video from TED.
Iterative and Incremental Development – Explanation of the difference between incremental vs. iterative software development (IID) and the history of IID.
Why Estimate Twice? – Good overview on the common practice of estimating the size of features, while estimating the duration of tasks.