Sprint Retrospective is the opportunity for the entire Agile Team (Product Owner, Scrum Master and Development Team) to inspect and create an action plan for improvements to the next sprint. The meeting helps the entire team to identify what worked well, and what should be improved.

I have some tips for making sure the meetings go swimmingly:

  1. The Scrum Master must be well prepared as a facilitator for the meeting.

There are thousands of retrospective techniques published in books and blogs, which when applied well achieve wonderful results. The main question is how and when to apply one particular technique or flow rather than another. However, an important issue is not only knowing the technique but knowing how to facilitate a retrospective.

Expertise in conducting good retrospectives is only gained after a period of experience. There is no single way for the Scrum Master to conduct good retrospective meetings.

The points below will help the Scrum Master to be prepared for the meeting:

  • Be prepared: Collecting relevant facts prior to the sprint cuts out the discussion as to whether, say, we have 20 or 25 stories completed.
  • Let all participants express their points of view.
  • The more the Scrum Master knows the team and the people, the more efficiently he or she can conduct the meeting. Get to know you team mates, and help them express themselves.
  1. Choose a good time for the meeting.

The scheduled day and time of a Sprint Retrospective is very important, because depending on the team and the daily work scenario, people may be tired, or focused on other important aspects such as deployment or bug fixes. You have to make sure everyone is available. First thing on the day after the sprint finishes sound good, but team members may also need time to gather their thoughts.

  1. The product owner needs to be present.

It is critical that the product owner is present to make a meeting effective and more productive. This is even written in the Scrum Guide. The first sentence of the Scrum Guide on Sprint Retrospective is as follows: “The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create an improvement plan to be implemented in the next Sprint.”

Since the Scrum Team is composed of the three Scrum roles, including the product owner him/herself. The presence of the product owner is mandatory, whether or not your Scrum Team enjoys it.

  1. Do not look for the guilty.

One of the biggest fears when people enter a Sprint Retrospective is that the meeting becomes a witch hunt, where the only thing that matters is to find whoever is guilty for the problems. To avoid this, it is very important that the team understand the objectiveness of the meeting. The team should be prepared from the outset to listen to constructive criticisms so that they can create an action plan of improvements for the next sprints.

This will only be achieved after a time of maturation of the team within the Agile methodology, so these discussions should be encouraged by the Scrum Master.

Agile Development: Project Schedules on an Agile Methodology

If you come from a traditional project management background, or if you have a Project Management Office (PMO) that needs a project monitoring tool or status, then you’ll be used to Gantt charts; but in Agile we’ve got even better tools for the management and visualisation of progress.

Tracking the burndown graph that shows the evolution of the sprint is vital to the progress of the development cycle, as are Kanban boards that make it easier to see the task progression.

By using these two tools, we actually have significantly more control than with a complex Gantt chart. The tasks are the stories, which for the users have a clear outcome, as they can actually see the deliverable emerging.

The Kanban Board  is used to show progress of individual stories and their progression through the development cycle. There is no need to micro-manage the sub-tasks – just keep an eye on the story.

Kanban Board

 

 

 

.

Burndown Chart

 

 

 

 

 

The burndown shows the throughput of work, and how much there is to go. The work left to be done could be seen as both effort and complexity – because they are the same thing.

Here are some tips that can help you create these progress charts for Agile software development projects:

  • Don’t overcomplicate the Kanban board; just make sure it works and is being used.
  • The most granular level in the Agile timeline is that of the stories, so it is not necessary to include sub-tasks for the stories.
  • It does not make sense to control the timing of each story, since we are talking about the timing of each iteration (sprint), and the set of stories that compose these iterations.

The 7 Key Roles of the Executive Sponsor in Modern Project Management

Perhaps the most crucial roles in any project is the Executive Sponsor role. Often underestimated, weak project sponsorship leads towards a dramatic increase in failure rates, a waste of budget and prolonged deadlines.

All these pitfalls can be prevented with strong sponsorship, a sponsor that has some ‘skin in the game’ and can act as a conduit to the organization as a whole.

This article will show you the importance of efficient project sponsorship and point out the 5 key roles of the sponsor in the complex environment of international projects.

The Increased Complexity of Project Management

Project Management has become more complex. Over the past decades an increase in global connectivity, the demands of flexible business models and the assimilation of markets has led to more transformational projects. Project must now have an even greater business focus and business benefit.

 

 How does the Executive Sponsor fit into this framework?

The executive sponsor is the go-between the organization and the project management team. This position is a tightrope act between inefficient micromanagement on the one hand and too little involvement on the other hand.

Especially since the project’s benefits, results and potential shortcomings fall in his area of accountability, the executive sponsor must find the right balance between his need to control the outcome and his team’s need for self-determination and –management. He is the CEO of this temporary organisation.

 

Concerning the project, a successful sponsor therefore should:

#1: Be accountable for the project, responsibility may be delegated but the executive is ultimately accountable, he is the chairman of the board of this temporary organization (the project) 

#2 Guiding the Project Vision: The sponsor is the spokesman of the project. They own the business case and should be constantly vigilant that the project is set to achieve it.

#3 Unified Direction: The executive’s job is to motivate, gain commitment and communicate with other stakeholders and ensure that decision made are not undermined. The project manager has his delegated authority 

#4: Mentor the Project Manager: The sponsor holds close contact to the project manager and offers guidance and coaching while avoiding being overly controlling

#5: Control Project through appropriate governance : The sponsor is keep informed of the project progress against a plan. A project charter and/or Project initiation document should set tolerances and expectation on the level and frequency of reporting

#6: Make Decisions: Sometimes there have to be changes to the original project plan. The sponsor decisiveness support a fast turnaround in the project.

#7: Organize Resources: The sponsor makes sure that the project’s aims are fully realized by efficiently organizing the available resources. The is done by enabling cross functional integration and the commitment of resources

The Executive Sponsor: A Key Factor to Your Success?

Having the right sponsor in place is the only way to achieve significant results. They strive to keep a focus on the organization benefits of the project outcomes which support good decision making in the project.

How is your current project structured? Do you have a sponsor in place and do you see his or her benefits? Effective sponsorship is a key factor to your project’s success.

PRINCE2® has a detailed definition of the roles of the executive sponsor (Executive) supporting senior roles. Even if you are not using the PRINCE2 ® methodology there is still plenty to be learned from the roles defined within the methodology.

Our world is built up of plans and estimate, business judge the CEO’s and senior manager by the estimates they produce and how they deliver on them. Without estimate we can’t prepare for the future.

In our daily life we plan using estimates, like how long will it take us to get to the airport, how much will we need to put aside for our summer holidays (vacations?)

The process of doing estimates has significant influences on our decisions making. For example can we afford our trip to France, or how long do we leave for the airport before the flight. Failure to make accurate estimates could have a lasting impact. We could miss the flight, or we could overspend on the holiday resulting credit problems.

Clearly for big business and for smaller personal decision estimation is vital. It is no less vital for our development or business change project to have a handle on the costs and delivery timescales. But is estimation the way to do.

Business stakeholder need to incorporate the estimates into their cost and deliverables. They need to be bought into the estimate in order to buy into the project. When an estimate is asked for, it’s critical to understand why an estimate is needed.

In scrum we estimate in detail, scrutinise, reviewed and update these estimates regularity. But the purpose and timings of these estimates is not what the business stakeholders is looking for.

Business stakeholders want to have some idea of when they’ll get which features, the number of resources needed to meet a timeline, and of course costs. None of this information can be provided without taking time to do some estimation and planning.

To get to a satisfactory solution to the conflicting requirements we need to separate out the stakeholders requirements into the 3 elements and deal with them separately.

1 Planning –

Planning gives the business an idea of the resources timescales and activities. The act of planning is a large part of the value, not the piece of paper the plan is written on. This plan is not about specific component delivery but about how we deliver the cycles and more importantly it is to come to a shared understanding of what we as a team can achieve.

2 Budget –

Budgeting projects uses a top down approach, where you decompose only so far as you need to in order to have enough information to make your decision.

Budgeting can be done in much less time and Budgets make better sense “what can you do for €XX.xx” This approach clears the way for the product owner to set some of the priorities.

Secondly Knowing the customer’s or management budget expectation impacted the developers’ estimates. It’s called anchoring.

3) Agile Estimates –

It is easier to have confidence that we can accomplish small things than big things regardless of what number we attach to that smallness/bigness. Agile estimates are small, lower level and feed into the budget and cycles that we have set out.

We are close to the action and have more confidence that we can deliver the controlled delivery. Smaller results in less variations and the variation in estimates easily to manage. The delivery teams can then stand over their estimates.

Agilists must accept the need for revenue and budget forecasts to be taken seriously

It is easy to join the chorus of opinion that software project estimation is waste and must be eliminated. Whilst I can understand the objections to spending valuable time preparing and rationalizing a set of estimates for ill-defined features or projects.

Breaking it into the 3 process can satisfy bot the business and the agilest

The Specific Reasons Why a Scrum Master is Not a Project Manager

 

Companies new to Agile often fall into the crucial trap of mistaking the Scrum Master role with the role of a Project Manager. This often leads towards a dramatic detriment in productivity, since the Scrum Master role requires a very specific skillset which is entirely different from the more generalist role of a Project Manager.

 

This article will point out the main differences between those roles and help you to chose the right person for both positions to make your project a success.

 

The Classical Role of Project Management

 

The Project Manager leads the project on a day-to-day basis, controls, communicates and provides direction. His role can be summarizes into the four following categories:

 

#1: Manage Processes: The Project Manager gets the project “up and running”, selects the team, establishes milestones and project schedules with the team and leads the project on a daily basis

 

#2: Track Process: The Project Manager monitors the timely achievement of milestones, tracks team costs and investments, overseas the documentation and provides direction

 

#3: Facilitate Cross-Functional Collaboration: The Project Manager Identifies linkages between sub-projects and coordinates cross-team cooperation

#4: Communication: The coordination of key project-related messaging to internal and external audiences, as well as communicating project information to the line management are Project Management roles

The Specific Role of the Scrum Master

The Scrum Master on the other hand does not manage the team on a daily basis. His role is more of a coaching and a facilitation role regarding Scrum, which makes him the link between the project team and the client.

Scrum Masters cooperate closely with the Executive Sponsor. They ensure that the project complies with Scrum and that all processes are implemented properly. The role can be summarized into the 3 following categories:

#1: Overcome Stumbling Blocks: The Scrum Master steers the development, resolves problems and involves the right people in the development process

#2: Oversee the Groundwork: The Scrum Master keeps two eyes on user experience, functionality issues and feedback from all stakeholders

#3: Provide Guidance: Helping to facilitate changes and assist in the planning process while providing overall Scrum guidance is a crucial function of the Scrum Master

 

There you have the main difference:

The Scrum Master is there to help and assist with highly specific technical knowledge but not to manage the workflow.

Summary: The Scrum Master is not a Project Manager

 

The role of the Scrum Master is more specific and technical than the more general role of a Project Manager. Both are important. Confusing these roles however almost certainly leads towards failure in the execution of Agile – and towards huge losses.

 

Make sure you have these important positions covered with the right people.

Agile Priniples

Back to Basics: When was the last time you looked at the Agile Manifesto?

 

The Agile Software Development method was officially introduced in 2001 (http://agilemanifesto.org/). However, evidence of similar incremental software development methods dates back to as early as 1957. The recent hype due to the method’s continuous improvement and rapid development led to confusion and information clutter.

 

It is time to take it back to the basics today and focus on Agile’s core values.

 

Honestly, when was the last time you looked at the Agile Manifesto? If this has been a while ago, here is a quick summary to refresh your memory and help you focus on the core conceptual framework.

 

The Agile Manifesto – The Key to Success in Agile Development

 

The manifesto was laid out in February 2001, when 17 software developers met in Utah to discuss lightweight development methods. The results have been groundbreaking. Here are the main values and working principles.

 

The 4 Core Values of Agile

 

In order to uncover more user-friendly ways of software development, the following values have been announced.

 

Individuals and Interactions      >          Process and Tools

Working Software                           >          Comprehensive Documentation

Customer Collaboration                >          Contract Negotiation

Responding to Change                  >          Following a Plan

 

Are you following these core values in your recent Agile project? If not, do not be surprised if the project lacks in success.

 

The 12 Core Principles of Agile

 

#1: Customer Satisfaction: Develop valuable and useful software quick

#2: Welcome Change: Make changes during all stages of development

#3: Frequent Delivery: Produce little working chunks of software constantly

#4: Close Cooperation: Co-create the software with all stakeholders

#5: Motivate Individuals: Develop a working atmosphere of mutual trust

#6: Direct Communication: Talk to involved parties face-to-face as much as possible

#7: Working Software: Produce software that creates results

#8: Sustainable Development: Maintain a constant development pace

#9: Continuous Attention: Focus on technical excellence and good design

#10: Simplicity: Maximize the amount of work not done

#11: Self-Organization: Allow teams to self-organize around their strengths

#12: Regular Adaptation: Adapt to changing circumstances

 

These principles can be applied to almost all processes of your business. In Agile, they are crucial towards the efficient and timely achievement of real results.
These core values and Principles are vital to the implementation of an agile process, it is essential that you regularly look to these principle to ensure you are not just following a process but truly building an agile environment.

The Six Attributes of a User Story and Why They All Count

The current best practice in Agile Software Development to clearly and briefly describe the functionality from the end-user’s perspective is the User Story. High quality User Stories will become part of the product backlog iteration. Weak User Stories are a waste of time and should be avoided at all cost.

This article will teach you the six attributes every effective user story must possess to pass the backlog quality check and ensure you spend your time right.

 

The INVEST Mnemonic To Writing High Quality User Stories

This simple, yet profoundly powerful mnemonic is a creation of Bill Wake the co-inventor of Extreme Programming.

I = Independent

A great User Story has the potential to stand for itself. By following this criterion the story can be scheduled and implemented in any desired order. This makes the story usable in different contexts and for multiple concepts.

N = Negotiable… and Negotiated

Outstanding User Stories are co-created by the programmer and the user. Only the main essence is captured, while the details are steadily added and influence the whole backlog in an iterative manner.

 V = Valuable

All great stories add specific value to their target audience, in this case: the user. Especially when splitting stories, each individual piece should address one very specific area in which value is created, while telling the overall conceptual story.

 E = Estimable

Every User Story must be estimable in order to be considered for a ranking by the customer. The degree of ratability is directly linked to the story being negotiable. Only stories that are understood by all stakeholders are estimable in scope and budget.

S = Small

A Story should not be overwritten and only focus on one key value adding idea. Keeping it within the range of a few person-days and at most a few person-weeks ensures that the story will be estimable.

T = Testable

Stories must be testable in order to be considered for the product backlog. If a story is not testable due to a lack of information it probably is not estimable and does not provide specific value to the customer.

All of the six attributes have to be considered in order for the User Story to be implementable. They affect each other in an iterative manner. Shortcomings in one area may lead to an information deficit in another and towards an unusable story.

 

Take the time to check your User Stories for all of these attributes. Time has shown that a Feedback Circle of Proposing – Estimating – Implementing is the most effective way to produce a great User Story, implementable in many different contexts.

Where to with the user story when completed

A user story is typically functionality that will be visible to users, by users this includes end users, administrator’s manager. To create a user story will require a number of tasks to be completed. These tasks are often shared out among a range of people such as analysis’s, designers, programmers and testers so each has their own task. When put together the tasks complete the user story.

 

User stories appear on the Product Backlog and tasks appear on the sprint backlog.

Include INVEST workshops as part of good Scrum Master training and coaching.

Programme Management

I’m currently working with a multinational organisation to build out the strategy to empower the business to take advantage of new regulations coming in as a result of de-regulation in Europe (Hmmm). We are working on a Programme to implement the strategy to deal with these changes in our marketplace.

 

For me Programmes are not just a collection of related projects it’s significantly more than that, programmes are about strategy and projects are about tactics.  Programme management is overseeing the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisations strategic objectives.

 

Programmes deal with outcomes and projects deal with outputs (From MSP®). We do use Programme Management to coordinate related projects but that’s down the road and its not the primary reason to kick off a programme. The programme starts by taking the business strategy, targets, initiatives and policies and defining the vision, scope and priority of the outputs that will deliver the outcome.

How do we approach this.

Develop the Vision, this is the postcard from the future of state of the business. It is used as the focus for the programme and like any vision it should be compelling and clear. Failure to get a good visions statement weaken the programme, therefore time should be spent in developing it. Re-design the vision in the middle of the programme may cause confusion.

 

From a Vision we can tease out a target operating model for the future, the practices and process that will be need to be in place to deliver the vision.  The target operating model is the blueprint of the future and the programme manager has the responsibility to ensure that the blueprint is delivered.

 

The POTI model is useful in developing out the blueprint, for each element of the blueprint used it to analyse the processed, organisation change, technology and information required for the future

 

 Detail
Vision StatementWe want to enter new emerging market ABC
                PProcesses, Business Models of operations and functions including operating costs and performance levels
                OOrganizational structure, staffing levels, roles, skills required, organizational culture, supply chain and style
                TTechnology, buildings, IT Systems and tools, equipment, machinery and accommodation
                IInformation and data required for future operations

 

From defining these process, organisational changes, technology and Information the projects to deliver them become apparent.

The above is simplified method bases on MSP®. More details on the methodology is available with templates examples. Drop me a line to chat through it.

Agile Practiitioner

The PMI-ACP is not difficult  but it does throw up some strange questions as the PMI try to relate the traditional PMP material to the  Agile methodologies. Many of the analysis techniques like  earned value are difficult to related to software development in a waterfall environment and applying them to agile seems like an unnecessary overhead we have no BAC.  The good news is that it is all due to change.

The current exam focuses on Scrum , Lean, Agile Concepts (the manifesto)  Kanban and XP and then mixes them up to create situation questions relating to general management or Project management (servant leader, Emotional intelligence etc.)

Mike Griffiths book is still the best general book, though I don’t think it gives Lean the coverage that is needed for the ACP Exam. Be careful with the online PMI-ACP exam question available online as  many of them are absolute rubbish, frustratingly written in an unknown dialect of English with confusing or completely incorrect answers.

The Velocitech website is probably the best set of exams out there and Andy Crowe’s  book is a good reference book with exam questions for the ACP exam but it is not a complete guide.

I do suggest that you research Mike Coen (Scrum) and  Mary Poppendieck (Lean) material. Their  publication,  webinars and blogs are a good source. Ken Schwaber book the “the art of doing twice as much in half the time” is worth a read for motivation though not particularly useful ACP

The books if you have the time are;

    • User Stories Applied: For Agile Software Development – Mike Cohn
    • Agile Software Development with Scrum – Ken Schwaber & Mike Beedle
    • Extreme Programming Explained – Kent Beck
    • Agile Estimating and Planning – Mike Cohn
    • Lean Software Development: An Agile Toolkit – Mary & Tom Poppendieck
    • The Art of Agile Development – James Shore;

The Project Management Institute suggests a number of others on their website. These have changed from the previous exam  with 4 new books added and 4 removed. 2 are on Kanban alone.

The exam time is 3 hours with most of my student competing it in 1.5 hour and many in less than an hour. The question are not as tricky as the PMP exam, correct answers are more obvious and less where the answer required is the ‘‘best’ or ‘first’. Moving from agile concepts will catch you out, one minute we are taking about the customer, the next it’s a product owner and the next question may be from the point of view of a Project Manager.  

The course is a good course to get yourself up to speed as a traditional project manager, a middle manager or perhaps as a product owner. For developers or budding Scrum Masters It may not provide the level of detail and doesn’t deliver the ‘fun’ experience that agile encourages.

The course is changing with a different approach. It looks to me like it will concentrate more on the approach and mind-set and less on the specific concepts.  I suggest that it will aligned with the directions that the PMI have for the skills of  a combination of technical, leadership, and strategic and business management expertise

The new PMI-ACP exam will see a number of changes (PMP Exam Content Outline,) summarised below

There are sever domains of Agile practices

    1. Agile Principles and Mindset
    2. Value-driven Delivery
    3. Stakeholder Engagement
    4. Team Performance
    5. Adaptive Planning
    6. Problem Detection and Resolution
    7. Continuous Improvement (Product, Process, People)

The distribution of questions on the PMI-ACP exam paper are now based on the domains

  1. Agile Principles and Mindset – 16%
  2. Value-driven Delivery – 20%
  3. Stakeholder Engagement – 17%
  4. Team Performance – 16%
  5. Adaptive Planning – 12%
  6. Problem Detection and Resolution – 10%
  7. Continuous Improvement (Product, Process, People) – 9%

New Tools and Technique / Knowledge and Skills are added while many are removed from the new PMI-ACP exam syllabus. New items added including:

    1. Developmental mastery models (for example, Tuckman, Dreyfus, Shu Ha Ri)
    2. Participatory decision models (for example, convergent, shared collaboration)
    3. Agile hybrid models
    4. Managing with agile KPIs
    5. the Five WHYs
    6. retrospectives, intraspectives
    7. control limits
    8. pre-mortem (rule setting, failure analysis)
    9. fishbone diagram analysis
    10. minimal viable product (MVP)

Althris Training have worked with our partners to redevelop our course material for the new ACP exam. To keep you posted and get more updates on both drop me an email

Does ‘servant leader’ sound strange to you? After all, does it make sense to talk about leading a team so that it moves forward to achieve goals, while being behind it to tend to the wants and needs of team members? Yet in numerous project management situations this style of leadership can be very effective. What might look like incompatibility at first blush becomes a doubly positive force for obtaining better results faster and more efficiently.

Agile project management methods like Scrum are a case in point. Handling change and rapid development cycles requires intelligence and creativity from team members. Leaders that try to pull rank are likely to do more harm than good. On the condition that everybody understands the basic rules of engagement, the contributions to be made and the objectives to be met, hierarchical levels can be taken out of the equation.

A servant leader then:

  • Assures the well-being of the team and team members
  • Prioritizes his or her own actions to help team members solve problems (without dictating the solution)
  • Focuses on people, on the understanding that well-motivated and enthusiastic people will meet project targets and expectations best.

At the same time, the servant leader is also the lynchpin for communicating with sponsors, stakeholders and other management. This is as challenging as any other leadership approach. That means good servant leaders are usually the ones that have had the right training and experience. And the right training also instills the recognition that servant leadership is one possibility among several, to be applied as and when the situation calls for it.