How should we implement Scrum?
What are various roles and ceremonies of Scrum?
What is Scrum Methodology?
What meetings are required by Scrum?
Scrum is the most popular Agile Framework. Almost every software development team in the world is using some aspects of Scrum framework in some shape or form. However most Scrum implementations that I have seen are missing some crucial parts of the recipe preventing them from achieving the exceptional results promised by Scrum.
I’ve decided to write this article, providing a concise summary of Scrum framework and how I believe it really should be implemented.
What is Scrum?
This is Scrum:
The Scrum Flow
Piece of cake! Isn’t it? Now let’s look at each artefact, role and ceremony in more details:
Product backlog is an ordered list of various work item that needs to be done. These work items are called Product Backlog Items (PBI). Items at the top of the backlog have higher priorities and items at the bottom of the backlog have lower priority. No 2 items have the same priority. Every item has more priority than the item below it and less priority than the item above it. The product backlog is not a queue and can be constantly reprioritised and changed by the product owner.
Items at the top of the backlog are more refined and are more ready for the team to start working on and items lower in the backlog are larger and more abstract. PBIs can be various things including but not limited to requirements (user stories), bugs, Spikes and research tasks, tech debt, etc.
Product owner is the person ultimately responsible for the product. They steer the development by prioritising the work. Product owner has content authority of the user stories. Based on the input from the stakeholders and the product/team vision, the product owner makes decision on the work that needs to be done. Product owner is responsible for defining the “why” and the “what” but not the “how”.
Product owner not the boss of the team, they are just another team member like everyone else. They are however the boss of the product backlog. They own the backlog. They decide what gets built next by prioritising the backlog.
The most important attributes of product owner are:
Domain Expert (e.g. understand the product really well)
Available (e.g. sitting with the team)
Stakeholder manager (e.g. ability to say no to multiple directions)
Empowered (e.g. ability to make important decisions independently)
The best analogy for product owner is “The Doctor” form the “Doctor Who” show.
He has the weight of the world on his shoulder.
He prioritises. Some lives need to be sacrificed to save the universe. And the product owner needs to live with those decisions for the rest of his life.
There is so much on his mind. So many responsibilities, so many balls to juggle. So little time. Needs a TARDIS to go back in time to finish those jira cards just in time.
He has made so many mistakes but at the end of the day he has saved the product and the universe so many times.
He is the best negotiator in the world. Can negotiate Daleks and Iron Men out of blowing up the planet
He knows almost everything. He has breadth of knowledge.
He finds information and provides it in a consumable format.
He is always available any time anywhere. He has a TARDIS.
And most importantly he is empowered to make decisions.
The development team
The development team or the developers are the people who build the product. Developer in the context of Scrum does not mean a computer programmer. It means anyone who participates in the development of the product. For example Programmers, Testers, UX designers, Business analysts, Tech writers, Release Leads, Architects, etc are all developers. Basically everyone on the team except the Scrum Master and the product owner are developers (remember this for your PSM exam).
are responsible for defining the “How”, but they can also contribute and help
product owner on the “What” and the “Why”. The Dev team needs to remain stable
over long periods of time. We can’t add/remove developers to the team at will.
best Analogy for the Dev team is the Guardians of the Galaxy.
are NOT super heroes. They don’t
have super powers. Except for maybe Groot.
have T-shaped skills. Highly skilled at one thing but also a little skilled at
a few other things
may have their differences but they collaborate really well.
cover for each other.
may look selfish at first but they are prepared to die for each other.
all have their quirks, but do the right thing at the end of the day.
most importantly they do whatever it takes, whatever it takes, to get the job
Scrum Master is the Master of Scrum. When we say someone is the Scrum Master
does it mean everyone else are the Scrum Slaves? No, “Master” here refers to
mastery. It means the Scrum Master is highly skilled at Scrum. They are the
Scrum Coach for the team. The Scrum Master is the team facilitator and the
remover of impediments.
Masters are servant leaders. It means they lead without having authority, just
like Nelson Mandela, Mahatma Gandhi, and many other servant leaders in history.
They persuade rather than using authority and lead rather than manage. The Scrum
Master is not the boss and the team don’t report to the Scrum Master.
Scrum Master is more of a “Servant” rather than a “Master”. They need to server
the team and make sure the team gets whatever they need to work at optimum
best analogy for the Scrum Masters are Jedi Knights from the Star Wars Saga
Scrum Master is the glue for the team.
has great relationships with everyone.
is a facilitator.
sure the processes that the team agree upon are followed.
is the impediment bulldozer.
users a light-sabre to open up the path for storm developers (storm troopers)
to move forward into enemy territory.
is diplomatic but not political. Witty and clever but righteous.
travels across the galaxy to facilitate and remove impediments.
most importantly he uses “the force” to sense impediments before they are even
the Sprint Planning meeting, the team plans for the sprint. The sprint planning
is time boxed maximum of 4 hours for 2 week sprints. This meeting happens at
the beginning of the sprint. At this sprint we talk about how much work can be
done this sprint and how the chosen work will get done.
this meeting the team starts picking up PBIs from the top of the product
backlog. They discuss each item and clarify questions with the product owner. They
estimate the PBI if not already estimated and start thinking about implementation
on a very high level and not too much in technical details. Then they will move
to the next PBI from the product backlog. The team repeats this until they feel
they are at capacity.
work that the team plans to deliver this sprint is called the Sprint backlog. Then
based on the work that the team has picked up in the sprint backlog, they
construct a Sprint goal.
the team commits to deliver the sprint backlog by the end of the sprint. And the
product owner commits not to change anything in the sprint backlog during the
sprint. If the product owner makes any changes it will void the team’s
that the Scrum Guide has removed the word “commitment” and replaced it with “forecast”.
I personally still prefer to call it commitment rather than a forecast. At the
end of the day, every team needs to assess this in their context to see if they
are happy to consider the sprint backlog as a commitment or prefer to think of
it as a forecast.
mentioned above the sprint backlog is the plan that the team comes up with for
the sprint. The sprint backlog is owned by the developers. The order of items
in the sprint backlog is decided by the dev team not the product owner (unlike
the product backlog). The product owner cannot make any changes to the sprint
backlog. If the product owner needs to absolutely make changes to the sprint
backlog in certain circumstances, they will void the commitment/forecast of the
team to deliver what they said they will in the sprint.
refinement (A.k.A. Backlog Grooming) is the process of refining and preparing
the PBIs for the upcoming sprints. Typically there is a backlog refinement
meeting to talk about and estimate the PBIs prior to the sprint planning. The better
we prepare and refine the PBIs before the planning meeting the shorter and
easier the planning meeting becomes.
is a short timebox where the team refines, builds, and tests PBIs. At the end
of the sprint a potentially shippable product implement must be produced. Typically
sprints are 2 weeks but it can be really any length, I have seen 4 week
sprints, 3 week sprints, 2 week sprints, 1 week sprints and even 2.5 day
sprints. It is a decision that needs to be made according to the context.
that once we set the sprint length we don’t want to change it and we want to
keep the cadence.
sprint the team iterates and goes through the same process again, incrementally
delivering potentially shippable product increments.
Scrum or Daily Standup is a short meeting that happens every day while standing
up next to the team kanban task board. The Daily stand-up is timeboxed to
maximum of 15 minutes but ideally you want to finish your standup in 5 minutes.
daily Scrum is not a problem solving venue. Neither is a status update. The daily
Scrum is a venue primarily for identifying impediments. It is also a venue for confirming
if we are still on track with achieving the sprint goals.
are 3 questions that everyone needs to answer in the daily stand up:
What did I do yesterday?
What will I do today?
do I have any impediments?
daily Scrum is followed by a meet after in case some people need to discuss
anything specific or get into more detailed conversation
is quite common that developers decide if they are going to pair with anyone
during the standup.
Potentially shippable product
increment and the definition of done (DoD)
team will have a definition of Done (DOD). This is to align what done means. So
we are not going to have conversations like is it done or is it done done?
team needs to write the DoD, print it, and put it on their wall. The DoD
defines what a potentially shippable product increment means. Ultimately Done
in Scrum means released to customers. However in most cases it is not practical
to release to customers within each sprint. For a start, most teams do not have
continuous delivery pipeline. Even if they did have it, deployed to production
does not necessarily mean released to customers. This is because typically
there are other activities such as documentation, customer communication, marketing,
compliance and many other activities that need to be done before new features
are released to customers.
“potentially shippable” in potentially shippable product increment is referring
to this. That shipping the product is a business decision. The team needs to
make sure it is potentially shippable and the business makes the call to ship
it or not.
very common Definition of Done that I see all the time is deployed on staging
and approved by product owner. However Scrum teams need to strive to move their
done to mean released to customers. Over time they need to bring those extra activates
within the sprint and the capabilities of the team to make sure they can go all
the way until value is realised by the customer and only then call it done.
sprint review is the event that the team (including the product owner) demo the
work they have done during this sprint to a wider stakeholder group. The primary
purpose of sprint review is to inspect and adapt the product and get feedback
from the wider stakeholder group.
let be quite clear. Sprint review is
not just a “showcase”. Please stop calling sprint review “showcase”.
sprint review a showcase trivialises the review to a just a demo rather than a collaborative
session where stakeholders provide feedback. It is a review of the potentially
shippable product increment not a showcase of what we did in the sprint.
the event where the team focuses on themselves and the process. They inspect
and adapt the previous sprint. During the retrospective the team looks at the
sprint and brainstorm on what to keep and what to change. Every retro needs to
have 1-3 actions. The teams need to come up with experiments and implement
them. Then review their experiments in future retro. We want to inspect and
adapt in short small cycles that is why we do a retro every sprint.
is based on empirical process control theory. Empiricism is what the scientific
method is based on. It means in scrum every opinion remains a hypothesis until
it is validated.
order to have empirical process control we need to have transparency,
inspection and adaption. It means we come up with hypotheses, we keep a transparent
environment, we inspect, and based on our learning, we adapt.
is designed in a way to maximise transparency, inspection, and adaption. Ken
Schwaber, one of the original creators of Scrum, puts it this way: Scrum is like
your mother-in-law, it points out all your faults.
The Scrum Core
diagram depicts what is at the core of Scrum.
I made this diagram based on what I learned from Alistair Cockburn from his heart of agile course. I have tweaked and adapted it a little.
is all it comes down to. Do this and you are doing it right, don’t do this and
you are doing it wrong.
The Scrum Core
my opinion, if you are missing any of the 4 items at the core of Scrum, you are
not doing scrum.
you have stand-ups and sprint planning, and all the details of the framework
but you are not delivering or demoing every sprint you are not doing scrum.
you are highly efficient and your velocity has improved 10 fold in the past quarter
but you are not focusing on the highest value first you are not doing Scrum.
If you are following all the rules of the scrum guide but your testers are all offshore and programmers need to do a handover to them you are not doing scrum.
you are delivering working software every sprint and your customers are happy
and it’s all rainbows and butterflies but you are not making changes based on
your retro actions you are not doing Scrum.
make sure to focus on highest business value first, deliver (or demo) every
sprint, have a cross functional team, and inspect and adapt every sprint. The rest
should get the basics right first then move to the details. Focus on the core
always while you are implementing the various scrum artefacts, roles, and
ceremonies. And make sure you evaluate everything with these principles.
Which Agile certificate is right for me?
Should I get Scrum Master Certificate?
What is the difference of Scrum Alliance and SAFe certificates?
What is the difference of various Agile and Scrum certificates?
Below is a comparison of some of the most popular Agile certificates. This is by no means an exhaustive list of Agile certificates. Some of these certificates are more generic and some are for specific Agile methodologies or frameworks. Some of these certificates have various levels, from basic to advanced, but we are not looking at each individual level and we are looking at them as a bundle. Now let’s have a look.
Certified ScrumMaster (CSM)
Scrum Alliance CSM is the most well recognised Agile certificate internationally with hundreds of thousands of people worldwide being Certified ScrumMasters.
This certificate is all about Scrum. It is a great entry level certificate especially if you are new to Agile.
CSM is mainly about how to be a Scrum Master. It is focused on the team level. Scaling is mentioned in the course but the focus is certainly not on large enterprises.
There is an easy online test that you need to take after the course and upon passing you’ll become certified.
Certified Scrum Product Owner (CSPO)
Scrum Alliance CSPO is about the role of product owner in a Scrum team. This course is also highly Scrum focused. The course also covers valuable product ownership and product management techniques such as user story mapping, various prioritisation techniques (e.g. WSJF, Kano analysis, MoSCoW), etc. There is probably around 50% content overlap with CSM depending on your trainer.
Professional Scrum Master (PSM)
This course is similar to CSM; highly Scrum focused. You can take the PSM exam without taking the course. But the exam is relatively hard and maybe a challenge passing if you don’t take the course.
It is typically the choice for people on budgetary constraints as attending the course is not a prerequisite for the certificate.
Professional Scrum Product Owner (PSPO)
Again, similar to CSPO but it is not required to attend the course and you can directly take the exam.
Similar to PSM, PSPO a good choice if you have budgetary constraints but the exam is relatively hard, so be prepared to study well before taking it.
One of the key factors that must be taken into account for any SAFe training is the trainer. It is very easy to become a SAFe trainer. So there are a large number of SAFe trainers who provide very low quality service and don’t really know what they are talking about. You must absolutely know your trainer before booking in otherwise you’ll be very disappointed.
SAFe Scrum Master (SSM)
SAFe Scrum Master focuses on the role of Scrum Master (or Iteration Manager) in large enterprises. About half of the course is focused on the team level and the other half is about how to operate an Agile team within a larger enterprise comprising of multiple teams, and portfolios where hundreds of people have to work together to deliver a working product.
SAFe Product Owner/Product Manager (POPM)
The POPM course is mostly process focused. It focuses on how to be a Product Owner or Product Manager in the context of a SAFe enterprise. There is some content on product management techniques in general but it is not the main focus of this course. The course is mostly designed for people who are from the business side and are moving to a PO or PM role in an enterprise.
Leading SAFe (SAFe Agilist)
SAFe Agilist is my favourite course. It is highly focused on underlying lean and agile principles and values. The course is designed for leaders and managers in large enterprises. However, I think it is super valuable for anyone who works in an agile environment.
The main focus of the course is how to think Lean and Agile beyond just the processes and practices in large enterprises.
Now just to be clear this is a super difficult course to teach. So unless you are doing this course with a highly skilled trainer you will be pretty much wasting your time and will not get the benefits of the course.
Large Scale Scrum has a very strict assessment and selection criteria for trainers. As a result, most LeSS trainers are highly skilled and deliver exceptional courses. I did my LeSS practitioner with my friend Venkatesh Krishnamurthy, and would absolutely recommend his course.
LeSS has a purist approach to transformation. It encourages doing whatever it takes to maximize the agility of the organisation.
ICAgile provides various certificates. ICAgile certificates are generally good, but typically it is relatively easy to become an ICAgile trainer. Again, I recommend to know your trainers before booking in. The current president of ICAgile Ahmed Sidky is one of my Agile heroes. He is absolutely fantastic in cutting all the fluff and focusing on what Agile really stands for. He takes the complexity out and focuses on the fundamentals.
This one is not really an Agile certificate. Prince 2 is a traditional project management methodology (like PMBOK). My personal opinion is Prince2 Agile is a misnomer.
It is a great certificate if you want to learn project management, but not Agile.
This certificate from the Project Management Institute focuses on Agile Project Management. Unlike most other certificates PMI requires real world experience and does not purely rely on classroom training and exam. Again similar to Prince2 Agile, PMI-ACP has a lot of focus on traditional project management.
Having Certificates does not necessarily mean you are an expert. We spend 2 days in a course and take the exam and then in a few months, we will lose all that knowledge if we don’t practice them. But unfortunately, in today’s job market certificates are considered a type of endorsement via accreditation. In many situations, having certificates is the prerequisite for even being considered for roles in the market.
In my opinion, the most important thing to consider is your trainer. A great trainer could inspire you for life. Even a 2 day session with a great trainer could change your life and plunge your career forward in a completely different way.
This happened to me when I attended the Heart of Agile course by Alistair Cockburn. Alistair’s course was such an inspiration to me. I always thought I know Agile and Scrum, but when I attended Alistair’s course I realised I know nothing. That course sparked a chain reaction that led to a super accelerated career growth ending up where I am today in just 3 years.
My mission now is to do what Alistair did to me. To inspire my students. To light that spark which will lead to their chain reaction. This is what drives me.
The quality of the courses that I deliver is of the utmost importance to me. When I go to the class in the morning my goal is to inspire people to a degree that will change their life.
I care about my students. As a result, we build strong bonds. I remember most of my students and we stay in touch. They also build strong bonds together. Relationships that last long.
So my ultimate recommendation is, don’t chose a certificate, choose a trainer.
What are the best certificates for the role I’m applying for?
Below is my recommendation for certificates that would help with the following positions.
(CSM or PSM) plus SSM
(CSPO or PSPO) plus (SAFe Agilist or POPM)
All of them, as many as you can. You are a coach, this is your craft you need to know Agile better than everyone in the world.
There are all sorts of advanced certificates like certified scrum professional, Certified Team Coach, SAFe Program Consultant, and other coaching level certificates. But I believe coaches need to already have all the entry-level certificates before moving to the advanced ones.
Agile Project manager:
PMI-ACP plus SAFe Agilist
Leaders and Managers:
SAFe Agilist plus Certified LeSS Practitioner
Hope this article was helpful. Thanks for reading.
What are the roles and responsibilities defined by SAFe Agile?
What is the list of meetings in Scaled Agile Framework?
What are some of the artefacts produced or delivered by various levels of SAFe?
What ceremonies various agile teams do in SAFe?
Scaled Agile Framework® is quite a comprehensive framework addressing various levels of organisations. SAFe® is a huge toolbox that you can use to address your organisational needs. It includes constructs that are fit for purpose for various contexts. Some critics say the size and complexity of SAFe is one of its disadvantages. In this article I attempt to create a list that summarises the roles, artefact, and ceremonies of Scaled Agile Framework.
Being framework it means you can pick and choose what is fit for purpose in your specific context. Obviously, there are other roles in organisations that are not explicitly defined in SAFe.
By all means this is not an exhaustive list, but a list of most common and important roles, artefacts, and ceremonies. There are functions that are talked about in safe but no specific role defined for them (e.g. Agile PMO, Lean Agile Centre of Excellence, Lean UX, System Team, CoP, etc.)
Similarly there are ceremonies and artefacts that are described in SAFe but I’ve decided to leave them out from this list E.g. vision and roadmap, portfolio ceremonies, etc.
Here we are only focusing on the core of the framework. We also have roles, ceremonies, and artefacts for the transformation process and DevOps such as value stream mapping which are not identified as part of this document.
Obviously this is only a summary, and to be able to get the most out of your SAFe Agile implementation you will need to evaluate the entire framework. Artefacts Like Vision and Roadmap and other SAFe constructs that are missing from the above list are super important and must not be overlooked in your SAFe implementation.
Please feel free to contact us for free advice on quick questions. Alternatively you can engage us for more in debt analysis and formal consultation.
At the end of the day SAFe is just another framework and must not be applied as a cookie cutter. You need to engage highly skilled professionals to help you make the best decisions in your context if you’d like to make the most out of your agile transformation.
Can your Scrum team be geographically distributed?
What are the challenges of offshoring and outsourcing in Agile environments?
How can you benefit from agile when your squads are geographically distributed?
How can we implement agile frameworks in multi-vendor teams across multiple offices?
In 2016 I had the privilege of presenting in the Scrum Australia Conference on setting up distributed multi-vendor Agile teams. Scrum Australia is the foremost Scrum event in Australia and is the only Scrum Alliance endorsed conference down under.
According to the 12th State of Agile report, distributed Agile is becoming the norm in the industry with almost 80% of the respondents having at least one team practising distributed agile. When Agile manifesto was developed about 20 years ago, distributed teams were not as prevalent as today. With the technological advancements of the past few years, nowadays, distributed teams and outsourcing is a viable solution for accessing specialised skills, cost saving, and risk management.
Now the question is how can we fully embrace the values and principles of agile manifesto in a distributed environment? In particular, how can we maximise collaboration, communication, trust, transparency, empiricism and everything else Agile stands for when team members do not physically sit and work next to each other?
As eloquently described by Dantar Oosterwal, modern day product development can be described as the “process of converting uncertainty to knowledge”
The speed and quality of product development depends on the bandwidth of communication between team members. When I attended Alistair Cockburn’s Heart of Agile course in 2016, one of the first activities we did was to identify what slows down the movement of ideas between minds? Then this list became our improvement backlog; the list of impediments to remove so we can speed up the movement of ideas between minds. Effectively increasing the communication bandwidth.
“Communication is like perfume it gets stronger the closer you get” ~Alistair Cockburn
Medium’s ability to handle multiple information cues simultaneously
Medium’s ability to facilitate rapid feedback and near real time information exchange
Mediums ability to establish personal focus
At the top of the spectrum we have face to face communication next to a whiteboard. And at the bottom of the spectrum we have emails and documents.
In distributed environments we don’t have the luxury of face to face communication so we have to settle for the next best thing which is high quality video conferencing or video recording messages (in case of time zone differences)
Making sure communication takes place is super important but it is not enough. We also need to make sure the quality of communication is good. We need to make sure there is transparency and trust in the team.
Building trust in distributed teams is very challenging. People naturally build trust when they live and work together and interact on daily basis. Human beings are social and it is super important to spend time together to build trust.
Lower levels of trust, fear, and lack of transparency are very common symptoms when there is a client/vendor relationship. Particularly when there are multiple vendors involved. It is of upmost important for coaches to keep a watchful eye on trust, transparency, and fear levels in these situations. Coaches must measure and proactively work on establishing an environment of trust and transparency where people are not afraid to speak the truth and to make mistakes.
In my opinion when there is a client/vendor relationship one of the biggest enemies of trust is trying to be too perfect. We are all humans and we make mistakes. Rather than trying to be political, and point figures, if we take responsibility for our actions and acknowledge our mistakes, people will respect us more and this will increase the trust levels significantly
After all, the Agile Manifesto values customer collaboration over contract negotiation, and individuals and interactions over processes and tools.
When working in distributed teams it is quite common for locations to be in different countries. In these situations cultural differences create another impediment for maximising communication and trust levels.
For example some cultures perceive asking questions as a sign of incompetence.
Let’s say you are talking about a very important topic in a meeting room with a few colleagues. And a developer from your vendor has dialled in from an offshore office. They probably do not have the context as much as you do, they do not have the deeper business understanding of the topic. They can’t see your body language, English is their second language, and they can’t hear you well because of low quality of the call. Compound all these with a cultural tendency of not asking questions because they don’t want to look incompetent in front of an important client.
I believe in this situation the onsite person is responsible to make sure the offshore person has fully understood what was communicated.
Another example is that some cultures perceive saying “no” as a taboo. Especially to people of higher status (e.g. boss, client, etc). In these cultures you have to understand from body language when yes means yeas and when yes means no.
Let’s say you ask your team “is it possible to deliver this user story in the next two weeks?” and they say yes sir of course it is possible. Then at the end of the 2 weeks nothing is delivered. And when you follow up and you hear irrelevant excuses. Have you ever been in that situation before?
If someone understands this culture they will know from the body language that even though they said yes they really meant “Are you crazy? This is impossible”
Again in this situation I believe it is the responsibility of the onsite person to make sure they learn the body language of the offshore culture and understand the way they communicate.
Cultures don’t change overnight and if we want to succeed in globally distributed agile business we need to fully learn and embrace the culture of our off shore teams. As coaches we need to educate both onsite and offshore staff about the importance of taking cultural difference into account and to think about them in our day to day activities.
Lewis cross cultural model provides in depth analysis of business cultures across various countries.
What can we do about it?
Below is a list of pragmatic things you could experiment with to make things better in your distributed agile teams.
1. Office setup and technology
Office set up is a key in providing an environment which promotes collaboration in distributed agile teams and squads.
The image above illustrates how a typical distributed squad work environment looks like at both locations. There will be an always-on video conference link between the locations (e.g. BlueJeans session). Wide angle webcam makes sure not only the entire team area is visible but the actual physical board is also visible at both ends.
We promote using both a physical wall and a virtual wall. Some aspects of the wall may be replicated according to the squad discretion but it is not required to replicate everything. For example the physical wall may have the squads charter, goals, vision, agile educational posters etc. and not just the kanban board.
With this setup, people can see each other and can walk up to the camera and wave if they need to talk with someone. This setup highly encourages collaboration and communication in a distributed environment. It makes talking to your offshore peers as easy as emailing, messaging, or calling them.
The image below shows an example of similar set up. Even though this is a low resolution image you can clearly see facial expressions and body language of the offshore team. You can clearly understand who is talking and who is looking at who. there are multiple information cues available simultaneously.
Credit: REA Group Blog
For longer meetings where in depth conversation is required, distributed meetings can happen in meeting rooms with the following set up.
Credit: The Distributed Scrum Primer by Pete Deemer
2. Frequent travel
Frequent travel is one of the biggest investments you can do when setting up distributed agile teams. Travel means people get to know each other, build relationships, establish trust, and get to learn each other’s cultures.
The best way to understand the pains and challenges of offshore teams is to go offshore and do your day to day work from their location. Only then you will understand the hoops they have to jump through just to do their day to day work.
This means we will appreciate their situation and take it into account when working with them. This kind of empathy significantly increases collaboration and communication quality as we will know when there is a higher chance of misunderstanding.
3. Have trust budget
This budget is protected and is spent by the program on what they see fit as a trust building solutions. For example the trust budget can be spent on travel, social activities, distributed hackathons, distributed charity works by the squads, and other distributed team building activities.
Distributed teams need to spend more days on team building activities compared to co-located teams. Some examples of distributed or virtual team building activities can be found here:
In distributed teams we have to go out of your way to build trust with offshore teams. Again, I believe travel is the single most important thing you can do to build trust in distributed teams and to improve collaboration by appreciating the challenges of the other side.
We may have all the skill required for effective in person communication, but that does not mean we are an effective online communicator. We need to invest in educating our team on how to effectively communicate on teleconferences, videoconferencing, and chat rooms.
I found teleconference meeting etiquette training quite useful. Things like making sure people talk to the teleconference microphone instead of talking to each other. When we are talking to the phone we talk differently to when we talk to a person face to face. We use different information cues to make sure the person at the other end understands us. When in a meeting, even if we are talking to the person in front of us we must actually pretend to talk to the phone. This makes sure the person at the other end understands what we are talking about and they don’t get lost.
Cultural education is also super important. We must educate our team what are the cultural difference of various locations. The offshore team needs to understand the onsite culture and the onsite team needs to understand the offshore culture.
Saying something is only 50% of communication. We need to make sure the person at the other end has understood what we were trying to communicate. And this is only achievable when we have understanding of each other’s culture.
I believe there is one situation when it is almost impossible to make agile work in distributed teams. And that is when each location is grouped by skill. For example all your developers are on site but all your testers are offshore. This creates silos that are further reinforced by geographic separation.
Having cross functional teams is one of the most important underlying philosophies of Agile. So the single most important thing to do in distribute agile is to have cross functional teams at each location. This is absolutely the most important takeaway from this blog. DO NOT CREATE SILOS AND PUT THEM IN GEOGRAPHICALLY SEPARATE OFFICES.
If you have such silos try to at least add one person from a different department/chapter to balance out and create some cross-functionality. E.g. if your business analysts and Product owners are onsite and your developers and testers are offshore, send one Business analyst to offshore and bring in one developer or tester onsite.
Are we approaching an era where there is no more a place for project managers in the software development life cycle?
Is agile project manager an oxymoron?
Why don’t we have project managers in Scrum?
With the popularisation of Lean and Agile based ways of working in the past decade there is no doubt that software development is moving away from a project based mindset to a product based mindset.
Credit: InfoQ: #noprojects – A Culture of Continuous Value
The above infographic has so much to say. We can talk about each one of the items in this image for pages. Each one of these items is worthy of its own blog. But today we are not going to elaborate on why we are moving to a #noproject approach. Instead we are going to talk about the role of project managers in a world that is moving towards #noproject way of working.
Lean-agile mindset promotes breaking down the roles and responsibilities of project managers across the team. Scrum in particular breaks down the responsibilities of the project manager and assigns them to the Scrum Master, Product Owner, and the Team.
On larger programs there are other roles (e.g. release train engineer and product manager at SAFe) that now take the additional responsibilities that project managers used to have in similarly sized projects before. These responsibilities include but not limited to managing scope, cost, quality, personnel, communication, risk, procurement and more.
With the #noproject way of working and the inversion of the iron triangle, all project manager responsibilities now can be handled in a distributed manner. So in theory project managers are not required any more in lean-agile ways of working.
Now let’s see if there is any situation where we actually need a project manager in an agile environment.
A pragmatic approach – Agile project Managers
Most Agile transformations are not big bang and there is transition period. Sometimes for various reasons organisations are not happy making the fundamental changes that are required for a true lean-agile transformation.
This means organisations usually build agile software development teams in a context which is not agile (agile teams in non-agile organisations). In these situations, agile way of working is forced in a non-agile context. Experts call this having team and technical agility without business agility.
For example many organisations still use traditional budgeting and forecasting, commit to detailed scope, set up temporary project teams, and in general do not use #noproject and the inverted iron triangle. But they use Scrum and “sprint” during their development and testing phases (i.e. cross functional small teams with short delivery iterations).
Having agile teams in non-agile context still does have significant benefits for organisations but to realise the orders of magnitudes improvements promised by agile case studies we need to fully transform the organisation and have both technical and business agility across the entire enterprise.
In these situations, an agile project manager is a very valuable resource as they both understand the non-agile way of working and agile ways of working. Agile project managers help bridge the gap between non agile business and agile team. It is a very difficult task as they are oiling a machine with two incompatible gears and making it work.
However, as more and more companies move to business agility and #noproject way of working what is going to happen to the role of agile project manager?
Conclusion, What the future beholds
Looking at my magic orb, I can see the silhouette of two possible futures:
More and more organisations will adopt the #noproject way of working and the inverted iron triangle. Eventually we will have a perfect world were project managers are not required any more for software development projects.
We will always have resistance towards business agility and enterprise wide adoption of #noproject approach. We will keep creating agile teams in non-agile organisations. In these situations, we will need agile project managers to bridge the gap between agile teams and the rest of the organisation that treat programs of works as projects instead of products/value Streams.
I think in reality we will probably end up somewhere in between. We will have more and more organisations moving towards #noproject. Over time some will regress back to project based way of working but in general we will have less positions available for agile project managers. So, we will not completely eliminate agile project management but require it less and less every day.
Our Leading SAFe course (with SAFe Agilist certificate) dives deeply in agile leadership questions like this one. Apart from discussing and answering questions like the role of project managers in Agile and SAFe, we spend over 2 hours discussing Agile portfolio management in large organisations.
What is the best funding model for Agile projects?
Can you have fixed cost Agile projects?
What does it mean to invert the iron triangle?
To be able to understand the Agile Funding Model we need to first discuss what it means to invert the iron triangle.
The project management triangle
The Iron Triangle (or Project Management Triangle, or Triple Constraint) is a model in project management used to illustrate the factors that constrain projects. The iron triangle shows that:
Quality is always constrained by Time, Budget, and Scope.
Changes to one constraint means other constraints need to change otherwise quality will be impacted.
Trade-offs need to be made between constraints for successful project execution.
According to this model it is impossible to commit to fixed cost, time, and scope of a project while maintaining quality.
Traditional approach to project management
In traditional project management we take the following steps more or less with similar order.
Define what we want to build
Define the detailed requirements to illustrate what our solution will look like
Break down the project into tasks via a work breakdown structure (WBS)
Figure out what skills we need to achieve the tasks
Hire the required human resources for the project according to the skills required
Estimate the tasks
Lay out a plan based on dependencies, who is going to do what by when
Calculate the time when the project is going to be finished based on the plan
Calculate the cost of the project based on resources accounted for in the plan
Execute (wishful thinking)
And this is what’s going to happen next. Every single time. There is no exception:
Things will not go according to the plan and changing the plan during the execution means the project constraints will be affected. This means significant reduction of quality, cost overruns, long delays, not delivering the committed requirements, or project complete failure.
So there are few options here, remember we can trade off the iron triangle constrains:
Add a lot of fat to your cost estimate
Add a lot of fat to your time estimate
Hide the poor quality of the product (apply lipstick to the pig!)
Trade-offs with Scope is usually the hardest
The third option is relatively easy in software products. This lack of quality will only become visible once users start using the system, or later when change is required to the system. The cost of change will be significantly high because of tech debt built into the solution.
Inverting the iron triangle
Agile has a very simple solution to this problem: change your view from “the world is predictable” to “the world is unpredictable”. How can we do that? By not committing to detailed requirements.
This is the recommended process based on Lean and Agile ways of working:
Define the high level outcome you’d like to achieve (not the output). This is the problem to be solved.
Decide a date when you’d like to have this delivered.
Empower your existing team to design and build a solution for this problem:
The team needs to solve the problem by the given date.
They may choose to design the solution based on current availability of skills.
Quality must be reasonable.
They are completely free to decide what the scope of work is as long as the solution addresses the specified problem.
Use iterative and incremental approach with empirical decision making.
The exact project cost is easy to calculate. The size and salary of the team is known, the delivery date is fixed. Team cost x project duration = project cost
So what is the difference of outcome and output? An example of an output is “I’d like an online book store website”. While an example of outcome is “I’d like to be able to sell books internationally”.
In this model the customer specifies the outcome they are after not the output they are after. And the team decided what is the best output to help the customer achieve their desired outcome. For example, maybe we should be using an eBay store as a starter to sell books online. Or maybe a mobile app suits the target market better than a website.
So basically we are articulating a problem. “What are we trying to achieve?” We will not be describing a solution. requirements describe a solution. We want to focus on the problem and let the team come up with the solution based on Lean Startup techniques, Agile ways of working, and empiricism.
Using this model, the customer will often get something they didn’t expect but it will always be something more valuable as it has been built iteratively and incrementally based on empirical evidence rather than human predictions.
This is what we mean by inverting the iron triangle. Instead of fixing scope and deriving the cost and time we will be fixing the time and cost and derive the scope
In the Leading SAFe® (SAFe® Agilist) course we teach how lean portfolio management uses the inverted iron triangle to enable lean funding instead of traditional cost centre funding. The summary of this funding model is described below.
The agile funding model
With Iron triangle inverted we can now fund teams instead of projects. This means we are moving from a push method of work allocation to a pull method of work allocation. To better understand this I’ll provide an example.
Let’s say we have a team of 100 people. And let’s say each person has an average day rate of $1000. Assuming a year contains 250 business days, this team will cost $25,000,000 per year.
100 x 250 x $1000 = $25,000,000
Now we know how much it costs to run a team for one year.
Assuming the team is working on a single value stream or product, budgeting becomes a much simpler tasks. The only thing we need to do is provide a vision for the team and let them build the product focusing on value and maximising ROI. In this example we will allocate $25 million per year to this value stream / product.
However, if we have a complex landscape with multiple in flight initiatives and competing priorities, then budgeting becomes more complicated and we will be required to do some level of small trade-offs between the constraints of the iron triangle. However this will be minimal compared to the traditional approach.
In this situation we have to break down our initiatives to large scale epics or features. Then we can use relative estimation techniques to estimate these epics in story points. And finally based on historical data we will estimate how long the team will take to deliver epics of this size. Then we can easily convert it to dollar values.
For example, if we forecast that based on historical data an initiative will take the team 3 months to deliver then we will immediately know that this initiative is estimated to cost $6,250,000
$25,000,000 / 4 = $6,250,000
This technique provides much more accurate cost estimate compared to traditional work breakdown structure and analysis based approach to estimation. Discussing why this is the case is beyond the scope of this article. I’m planning to write an article on relative estimation soon. So please stay tuned if you are more interested to learn how relative estimation works and why it is more accurate.
Obviously this is an oversimplified version of lean agile budgeting. The actual budgeting and forecasting process is more complex. To learn more about lean-agile budgeting please refer to SAFe® Lean budgets guide or attend one of our courses.
If you’d like to take your learning to the next level please refer to beyond budgeting. This is particularly valuable when articulating funding approaches to finance people. Beyond budgeting was developed by finance experts and aligns perfectly with Agile ways of working.
In agile we invert the iron triangle. Instead of defining what we want to build first and then deriving the cost and schedule we would define our budget and deadline and based on that come up with scope of the product.
This is Bad: I want an online car dealership store on WebSphere Commerce. The details of what I want is documented in this 350 page document. When can I have it and how much is it going to cost me?
This is good: I have $20 million and I want to be able to sell cars online by end of the year. What can you give me with those constraints?
In lean agile funding model instead of having cost centres and funding projects, we fund teams and value streams. This means we are moving from a push approach to a pull approach.
If you change your view from “the world is predictable” to “the world is unpredictable”, amazing things will happen.