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.