Let’s End the Debate! Scrum Master versus Project Manager – Part 2 of 3

Tuesday, November 13th, 2012

Missed part 1? Read it here: Let’s End the Debate! Scrum Master versus Project Manager – Part 1 of 3

 

Over the past couple of months, I’ve been documenting, in near real-time, the progress being made as an organization goes through an Agile transformation.

 

During this transformation, I’ve learned that there’s no way, going through Scrum Master training that I could be responsible for all the responsibilities of a project manager. It’s just not fathomable and would lead to ultimate project failure. To set the record straight, project manager is NOT synonymous with Scrum Master. A Scrum Master is critical to the facilitation and execution of the Scrum team. But they’re not responsible for all the components of a product development project. If anything, a Scrum master should be a dotted line to a project manager as part of the reporting structure.

 

However, for all these relationships to work together, we also need to know what the responsibilities are of the team back to the project manager.

 

Essentially, the project manager has to know just about everything that’s going on during the course of a project in order to determine if the right action and the necessary progress is being made against the tasks and deliverables. It’s unrealistic for every meeting and every action to be in the project manager’s schedule. However, they still need to know what meetings are occurring and when communication and decisions are expected in order to ensure the team is working effectively and efficiently relative to the agreed upon scope and success criteria of the project.

 

This relationship between the project manager and the team is not meant to be based on command and control, but rather based on trust and optimizing collaboration. If the project manager has any chance in managing these responsibilities while not having authority over most, if not all, of the team resources, then they need to rely on those team leads for basic and fundamental information. The following are the characteristics of the entire product team including the project manager:

  • Openness regarding truthful task and deliverable progress
  • Frequent and constant communication
  • Commitment to achieving the success criteria
  • Courage to tell the truth
  • Respect for each other

 

Borrowing the page of Scrum team responsibilities to the product owner and scrum master, I’ve tailored the responsibilities so that they reflect the entire project team relative to the project manager:

  • Communication regarding the prioritization (and change) of requirements, MMF’s, sprint backlog items, and tasks
  • Commitments to results based on agreed upon milestones
  • Communication of estimates of effort to implement User Stories and tasks to complete all project deliverables
  • Communication of dependencies between tasks and team members
  • Identification of obstacles and informing the project manager when those obstacles may occur and when they have occurred.
  • Self-organizing – Individual teams within a project have to be self-organizing and can’t rely on a command and control style project manager. However, self organizing means informing the project manager on how the team is self- organized and how they intend to complete the work. Project manager’s need to have context for any of this to make sense.
  • The team has the right to do everything within the project guidelines boundaries to achieve the project goals.

 

In the product development world, project managers, more than ever, are critical in the successful execution and delivery of projects/products to market. Role clarity and collaboration is essential. The project manager and the scrum master are meant to work collaboratively with each other not against each other. If we can get our definition of a project correct and we can enforce the responsibilities of the team back to the project manager, then I can say confidently “Project managers, there is no need to worry about job security. You’re still a valuable member to your organization. If anything, your job just got easier by the introduction of the scrum master and product owner roles.

 

Don’t forget to leave your comments below! Thanks!

 

Continue reading: Let’s End the Debate! Scrum Master versus Project Manager – Part 3 of 3

 

This is the second in a series of three guest posts on this topic from Steven Starke, author of S.T.O.P The Project Management Survival Plan and partner at Actuation Consulting.  

Steven StarkeSteven Starke is the author of S.T.O.P. – The Project Management Survival Plan. He is currently the VP of Program Management for Truven Health Analytics (formerly Thomson Reuters Health) and working with Actuation Consulting on training material focused on product team collaboration. Steve has held leadership positions in Program Management, Product Management, Systems Engineering, Product R&D, and Global IT and has run full-fledged PMOs. His industry experience ranges from consumer products and medical devices to global IT Infrastructure, healthcare analytics, and software development. Steven can be reached at Steve@actuationconsulting.com and networked with via his LinkedIn profile. Read more about Steven.

Tags: Agile product management, agile project Management, agile vs traditional, agile vs waterfall, scrum master vs project manager
Posted in Agile, Agile Project Management, Agile Tools, Agile Transition, Agile vs Traditionnal, Kanban, Reporting, Scrum, scrum-but | No Comments »

line

Learning Organization explores beyond Agile Constraints

Tuesday, August 16th, 2011

In September 2011, I decided to go full-time at iWeb Inc., a provider of simple and advanced, dedicated cloud-hosting solutions.

My mission was three-fold:

  1. Implement user-centric design methods in their strategic planing and application development practices.  Little note: iWeb Inc.’s application development team was evolving within the agile framework without sufficient research.
  2. Install an inspiring and structured new narrative concerning iWeb’s evolving Enterprise Architecture with the use of workflow visualizations and illustrated stories.
  3. Promote and teach the most efficient ways of tackling complex User Experience planning issues using creativity, storytelling and visual thinking skills.

The hardest part of synthesizing the SCRUM process is that like most Agile-driven approaches, it has a Coach and a strategic dialogue feel to it. Furthermore, since most evangelists of the movement do not come from creative fields, we perceived the culture differently and it quickly became a battle of semantics. We all know words and emotions create narratives that can get out of control…

Coming from an Interaction Design & Design Thinking field, I was looking for something with fewer meetings, more visual thinking and way more time spent inventing. I was constantly returning to the GTD basic principles to organize my tasks within the constraints of our Weekly Wall Planning and was looking for my GameStorming and Design Thinking Cards to challenge my assumptions. I began reading on project management theories that focused more on the value-creation paradigm emerging from the Agile Community. However it was only compared to other theories rather than wholly explained which left me still unconvinced…

I felt SCRUM was not handling the creative process properly. In fact, I discovered that creativity spurts were often dismissed in such an environment because a merit system was missing. Multidisciplinarity did not inspire individuals to necessarily create collaborative strategies. Complex task management tools create complex communication. The need to identify minimal product requirements was not well spread through the company and Product Owners were still all in a deep learning curve and the Process of Managing Creativity and Communications is more about managing complexity and trying to be Predictable without losing the Flow.  In the end the more we tried to encircle creative endeavours into specific boxes we were reducing the natural constraints effect which in return augmented the entropy effect of all our collective efforts.

Often the whole focus would be on developing the features that were packed into the ongoing Sprint (3 weeks). However no one was in charge of keeping the workflows lean without loosing sight of the big picture. I had read about the Pragmatic Marketing Framework and on how to build documentation for Design & Planning (see Communicating Design) but they had to be severely hacked to fit well within the Agile methodologies in place.

Then we branched the Front-End Web Design Integration Team with a IXD & UX Planner and Visual Designer and created a studio of Product Design & Service Blueprinting. Our services are:

Divergence Stages : Many Ideas not many Patterns

Strategic Phases

  1. User  & Market Research
  2. Business Modeling
  3. Strategy & Service Blueprinting
  4. Content Design

Exploration Stages: Less Ideas Few Patterns

  1. Models, Prototypes, Concepts

Convergence Stages: Clear MVP idea – More patterns

Tactics Phases

  1. Visual Research & MoodBoards
  2. User Interface Design
  3. Interaction Design
  4. Front-End Development

iWeb Kanban

To manage our projects & the tasks, we created our own Kanban Board and segmented projects using Creative Phases. Once a phase was complete we would move a colored post-it.   We currently Run most of our Task Reporting on JIRA, but we are moving to Planbox Agile Tool when we kickstart the new Product Design projects since its Visual Interface corresponds to what most Designers need from a Task Management Tool : A Coherent visual Flow and Efficient Features interactions.

Kanban Stages

Before we stick a project on the Kanban Board we make sure (with the Product Owner) that the minimal viable product feature set is determined through a Strategic Dialogue composed of three loops:  Divergence, Exploration and Convergence.

Posted in Kanban | 3 Comments »

line

Dipping Your Toes Into Kanban

Friday, January 21st, 2011

Planbox is glad to present David J. Bland from Scrumology.net, our first guest blogger of 2011.

dipping your toes into kanban

David is an Agile and ScrumMaster with 10 years experience in the technology industry who strives to find balance between Agile theory and Agile reality. He recently developed a keen interest for Kanban and we invited him to discuss it on our blog. And without further ado…

Like me, you may have read about the growing popularity of kanban in the agile software development community. Perhaps its mysterious allure and intriguing pronunciation (kahn-bahn not kayun-bayun) have piqued your curiosity, yet you struggle with finding a pragmatic way to apply it to your current software development process?

Interestingly enough, the beauty of kanban is that you can apply it to your two week iterations… right now if you like without that much disruption. In fact, you may even find it so useful that you’ll find other ways to work the kanban mojo.

Let me explain.

About a year ago an agile team walked into our iteration retrospective a bit down trodden. They felt as though their energy was being sucked from them at the beginning of every iteration due to the length of the tasking and design sessions. In addition to this, they would open all of the stories within the two week iteration at once and would jump around from story to story at will. They had also realized about half way through the iteration they had forgotten the conversations around the original tasking sessions. All of this added up to a great deal of frustration about the way they worked.

A couple suggestions were made within the iteration retrospective:

 

 

 

1. Apply a work in progress limit on how many stories are tasked in one sitting.
2. Apply a work in progress limit on the number of open stories within the iteration.

The team decided on a work in progress, or WIP, limit of 5 for tasking, and a WIP of 3 for open stories. These numbers were rather arbitrary, but we had to start somewhere.

Over the next few iterations, something almost magical happened.

Tasking and design sessions had a renewed energy

Tasking sessions no longer felt like a marathon to the team, with people routinely checking Twitter (ahem) and checking out mentally. We noticed that 6 days into the iteration, team members could remember why we had tasked a user story in such and such manner.

Now the downside of this was that we had more interruptions within the iteration as we would task in bunches on 2 or 3 separate occasions. At first the team felt a slight annoyance with this, but eventually adjusted and embraced the approach as the pros greatly outweighed the cons.

Team members had more focus with regards to the open stories

We found that the number of mistakes, errors and defects on our stories were drastically decreased. No longer were team members shifting from one story to another and back, but rather exhibiting a laser focus on the 3 open stories. There was a sense of urgency in the team room that was lacking beforehand. We knew that in order to open another story we had to finish one of the existing 3, and it helped foster collaboration. Team members would help each other to wrap things up, rather than jump around like they had in past iterations.

Now the downside of this was that at times the urgency turned into anxiety and we exceeded the WIP limit. When this occurred, we would address it in the iteration retrospective to see if we could uncover the root cause of exceeding our WIP. Those conversations generally lead to process improvement that may not have been discussed otherwise.

 

 

 

It doesn’t replace your current SDLC

Kanban is applied to what you do now. Purists may argue that applying it to 2 week iterations is not enough, and that you need to break out of the time box. Eventually, I can envision this as it seems like the natural progression, but it happens on your time schedule, when your team is ready.

So go ahead, dip your toes in and see if you like it.

Tags: agile, kanban, scrum, ScrumMaster
Posted in Kanban | 6 Comments »

line