Daily Standup in My Notes

Purpose

According to a pile of evidence shown in the Daily Scrum in the Scrum Guide, such as

The Daily Scrum optimises the probability that the Development Team will meet the Sprint Goal.

and

This is a key inspect and adapt meeting.

, I would say the fundamental purpose of Daily Scrum is

to help the team meet the Sprint Goal

through

inspecting progress since the last Daily Scrum

and

adapting the way of working during the upcoming Sprint work.

Basic rules

Five essential rules of Daily Scrum have been concluded in the playlist of Daily Stand-up Meeting (aka Daily Scrum), within which you can dive in the detailed explanations of these five basic rules. Although there are quite a lot of controversies about some of the rules, I do agree with all of them which are listed as follows.

  1. must do daily stand-up
  2. must do stand-up
  3. same time every day
  4. keep it short (not simple, but efficient and effective)
  5. stand up

And there is one additional rules that I would like to add to the list, which is

6. Each turn, only one person talks

As far as I’m concerned, why this rule is deemed as one of the bases can be answered from the following prospectives. Firstly, one of the Scrum Values guides the team members should respect each other, and one of the specific ways of respect is listening and not interrupting others’ speaking. Secondly, uninterrupted speaking ensures the meeting finished in the fix timescale, rather than lengthening the meeting duration in order to in-depth discussions. Then, the whole team would focus on figuring out the progress and blockers toward the Sprint Goal in this manner. Lastly, the clearly identified issues could improve communication and collaboration after the meeting accordingly toward completing the work as a team in the Sprint Backlog.

Attendees

The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.

The Scrum Guide

Speaking Order

This is an often ignored but important point of the Daily Scrum. An appropriate mechanism of speaking ordering will facilitate the Development Team members concentrating on what others are presenting as opposed to preparing speaking or thinking of other things, so as to improve communications, identify impediments and promote quick decision-making efficiently and effectively and so forth. Therefore, I suppose if the speaking ordering of each attendee would not reveal until he or she speaks, it should be working well to conflict with this potential tendency. The detailed discussion can be found in The Talking-in Order during the Daily Standup.

Being Late Penalty

In order to the agreement that the Daily Scrum MUST start on time, there may be attendees showing up late for the meetings. With regards to the penalties for the late arrivals, there are some of the most common rules including gold coin penalty, singing or doing push-ups, etc. However, Kym Gilhooly has recognised the drawbacks of these penalties and pointed out that these penalties cannot eliminate the problem of arriving late ultimately in 6 basic things you shouldn’t be doing during daily stand-up. Hence, the punishment for individuals being late is not a rather good solution. Conversely, it is better to let participants fully relieve their anger due to their time not being respected.

Structure

The Three Questions

The first one is the classic three questions (Yesterday-Today-Obstacles) around the work has done and will do, and the identified blockers. This is the most commonly used structure that has been introduced as a typical example in the Scrum Guide. And I also found an example IBM Agile Academy: Daily Stand-up Meeting that an Agile team conducted the meeting in this manner in IBM. The three-question structure provides a process for the meeting keeping participants pay attention to the work toward the Sprint Goal, as opposed to talking about all kinds of things that don’t relate to the team.

The Kanban-style

Kanban-style daily stand-ups focus more on:

  1. What obstacles are impeding my progress?
  2. (looking at the board from right to left) What has progressed?

In the episode Agile Daily Standup – How To Walk the Board (aka Walk the Wall), the interpretation of looking at the board from right to left has been indicated.

The Combination

It was pointed out that the three questions structure may cause members to focus more on their personal work, while the task-based structure may lead to the scattered speaking content. I reckon the combination of the two structure could eliminate the concerns. The specific process is each participant answers three questions sequentially according to the relevant tasks on the board from right to left.

In this manner, the three questions may still be used but will be from the perspective of the work item, rather than the person. As a result, knowledge transfer and internal communication would be greatly promoted and the Development Team members could take more opportunities to ask for help or collaborate ultimately.

The Three Questions again

The order

Let’s go back to see the purpose of Daily Scrum. I found this to be a progressive process, which is from reviewing the work that has been done to plan the next work in turns to optimising the possibility of achieving the Sprint Goal similarly to the Build-Measure-Learn feedback loop introduced in the Lean Startup framework. Consequently, I would say that the plan for the next work produced during the Daily Scrum should consist of two parts: the developing work and adaptations. In this case, the done work has been done and the spotted impediments need to be clarified before the plan is determined. So the priority of the three questions I suggesting could be:

  1. What did I do yesterday that helped the development team meet the sprint goal?
  2. Do I see any impediment that prevents me or the development team from meeting the sprint goal?
  3. What will I do today to help the development team meet the sprint goal?

The Fallacy

When I read some introductions and guidances of Daily Scrum, there may be something wrong I feeling. The above screenshot is the example indicating the three questions used in Daily Scrum. Will all questions be answered around the individual work? This is a misleading utterly. Although there is only a nuance between the questions displayed on some websites and the questions on the Scrum Guide literally, working as a team and helping to team meet the Sprint Goal should be strongly emphasised. This has been proved by the comment left by Dwayne Stroman in one of the misleading introduction episodes of Daily Scrum.

The 3 questions can easily lead this into a status meeting. The team should already know progress through collaboration. The daily scrum is about a new plan for the day, not a report of what I did and what i’m going to do. The questions should be “what progress did we make as a team?” and “what should we focus on today as a team?” and “What impediments do we face as a team?”

So, just use the version of the three questions presented in the Scrum Guide and keep working as a team in mind.

  1. What did I do yesterday that helped the development team meet the sprint goal?
  2. What will I do today to help the development team meet the sprint goal?
  3. Do I see any impediment that prevents me or the development team from meeting the sprint goal?

The Talking-in Order during the Daily Standup

When I search for some cases of Daily Standup, there is a very interesting point that people usually concern with, which is the talking-in order. Two questions emerge from it commonly as follows.

WHO IS THE FIRST?

and

WHO IS THE NEXT?

The Scrum Guide introduces the rules of Daily Standup meetings so simply, in which there is even no emphasis on the speaking order. So why? Are the answers to these two questions important? I reckon YES.

Firstly, I would say if there is no team member who has considered these kind of questions, there must be a fallacy among the Agile team. Who can decide which one’s speaking triggers the current Daily Standup meeting? And who can take charge of prioritising the speaking sequence of the development team members? Nobody can, not even the Scrum Master, but only the Development Team itself. The Scrum Guide indicates that

The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum.

As a self-organising team, the Development Team should make an agreement on the speaking order. If each member is asked to talk in sequentially by the facilitator, then it would be a bureaucratic report meeting.

Secondly, The Scrum Guide defines the Daily Standup is a 15-minute time-boxed meeting. The Development Team should inspect the work and plan for the next in such limited timespan in order to optimise the probability of meeting the Sprint Goal. Hence,

conducting Daily Standup meetings efficiently and effectively

is a crucial work the entire team has to contribute to, as opposed to performing simple status meetings. This is also the fundamental purpose of raising the two issues mentioned above.

Let’s have a look at some widely used approaches applied for the speaking order introduced by Jason Yip. Who is the person talking in first? One conventional solution is that last arrival speaks first, while Jason has also pointed out a tendency that “the last arrival is also likely to be the person who is least prepared to start off the meeting well“. With regard to the priority techniques (also includes picking up the first speaker), Jason lists three of them in his post It’s Not Just Standing Up: Patterns for Daily Standup Meetings, which are predictable ordering, unpredictable ordering and ‘Take a Card’ game. The detailed rules, benefits and drawbacks have been identified in the post. Although Jason did not point out the shortcomings of ‘Take a Card’ game, I do not think that this approach can help the team accomplish the fundamental purpose proposed above. There may still be a tendency to prepare or think of other things rather than pay attention to what others are saying in this manner.

As far as I’m concerned, a simple random system could be considered to build. Since the team has been formed ready, the Scrum Master input the names of all development team members into the system. At the beginning of Daily Standup meetings, the last arrival presses the button to produce a member’s name randomly who will speak first. After he or she finished, press the button to introduce the next member to talk in, and so on. I suppose the system could help each member focus on the current speaking and facilitate the efficiency and effectiveness of the meetings. Any suggestions?

Scrum Q&A

This is for recording the questions I met during learning and practising Scrum framework. And I will update more questions and try to present my own opinions continuously. If anyone catches something wrong in the content or has different views, please do not hesitate to discuss with me and I would appreciate greatly.


Questions

  • Q: Scrum is a rule-based framework. Does complying the Scrum’s rules conflict to Agile Manifesto?
    • A: Nope. There are three reasons I have found shown below.
      • ‘Individuals and interactions over processes and tools’ is listed at the first of the Manifesto for Agile Software Development. But it also indicated that it is a case of the relative importance of the values, and not a case of ‘good’ or ‘bad’.
      • The original purpose of Agile is to replace the heavyweight, document-driven processes that existed at the time. Concerning Scrum, it is a lightweight, iterative and incremental framework for managing complex knowledge work. Scrum challenges assumptions of the traditional and sequential approach to product development, and facilitate teams to become self-organise.
      • As one of the Agile Manifesto creators, Jim Highsmith has explained in Agile Manifesto History that ‘the Agile movement is not anti-methodology‘ and ‘we want to restore a balance‘. Such Agile frameworks and methodologies as Scrum, Kanban and XP (eXtreme Programming) have realised the balance by keeping their rules and practices to a minimum given the circumstances but focused on empowering developers of all kinds to collaborate and make decisions together as a group quickly and effectively.
  • Q: How many members made up a Scrum Team is appropriate?
    • A: As we know, a Scrum Team consists of three roles, which are the Scrum Master, the Product Owner and the Development Team. The Scrum Master and the Product Owner must be a sole person respectively. With respect to the Development Team, the Scrum Guide has claimed that the number of team members should be at least three and at most nine. Hence, the total number of a Scrum Team should be controlled from five to eleven. However, one specific condition indicated in the Scrum Guide should be considered is that the Scrum Master or the Product Owner can be one of the Development Team members if he or she also participates in the work of the Sprint Backlog. The PRINCE2 Agile manual introduces a typical guide of the Scrum Team size that it should be seven, plus or minus two.
  • Q: Is there any effective way to monitor progress during a Sprint?
    • A: There is no specific methods or tools mentioned in the Scrum Guide for monitoring Sprint progress. It’s because the duration of a Sprint is comparatively short, around two to four weeks. So it would be easy to track the progress for the Development Team during this period. However, in order to improve transparency and let everyone know the progress easier, it is a good idea to visualise the Sprint progress like monitoring the progress of the entire project. The burn-down chart is a typical technique that can be employed.
  • Q: Should the Sprint Review and the Sprint Retrospective be placed after a Sprint cancelled?
    • A: Once the Product Owner determines to cancel the Sprint, the Scrum Team should review and assess the work has been done and has not been done from the beginning of this Sprint to the present. This is one of the most essential tasks listed on the agenda of the Sprint Review. Although the Scrum Guide does not specify that the Sprint Retrospective needs to be sited at this time, I believe it is appropriate to inspect and adapt the work through this formal event. The actual duration of the Sprint would be less than its fixed duration basically if cancelled, consequently, the duration of the Sprint Review and the Sprint Retrospective should be shortened respectively.
  • Q: Will the Increment of each Sprint be released or deployed immediately?
    • A: It depends on the Product Owner. As the sole person accountable for the product, the Product Owner should organise the time to release each Increment in order to maximise value. Thus the Increment delivered during each Sprint must be deemed ‘Done’ and in useable condition regardless of whether the Product Owner decides to release it.
  • Q: How many improvements should be implemented during the upcoming Sprint appropriately?
    • A: The Scrum Guide has claimed it should be at least one item selected into the next Sprint Backlog. And I suppose that it is a good idea to prioritise the identified improvement tasks according to their urgency and estimated effort, and then select the items with the highest priority and within the tolerable effort based on the result. In this manner, the Scrum Team can ensure that only a few improvements to the process are suggested, as opposed to working on too many of them at the same time.
  • Q: Can the sprint end early if all tasks in the Sprint Backlog have been completed and the Sprint Goal is reached?
    • A: No. The Scrum Guide illustrates that ‘Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened’. However, there would be the case if the Scrum Team members have accomplished all work before the Sprint end date. In this situation, the Scrum Team must keep self-organising to find out and work on correct work in the remaining duration. There is a typical list of the work the Scrum Team can perform during this time.
      • Continuously refine Product Backlog items to ‘Ready’;
      • Identify and implement activities that improve quality or productivity or work;
      • Participating in practices or trains to adopt and understand Scrum and Agile better;
      • Learning or improving other relevant skills to become more cross-functional;
      • etc.
  • Q: Can the duration of a Sprint be shortened or lengthened?
    • A: Yes. The Scrum Team can make the decision for changing the Sprint length together as more is learned. Scrum is founded on empiricism and there is no specific limit of shortening or lengthening the Sprint duration if the Sprint has not commenced. Hence, changing the Sprint duration can be seen as an action that is identified and recorded in the improvement list for improving work and fitting the Scrum Team’s goals better during the Sprint Retrospective. In addition, each event must change its duration according to the new Sprint length.
  • Q: Can the duration of an event within a Sprint be shortened or lengthened?
    • A: Yes. The Scrum Guide demonstrates that ‘The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process‘. Consequently, if the Scrum Team has recognised that the prescribed length of a specific event is too much enough or too little for achieving its purpose, the Scrum Team should reset the event duration in the Sprint Retrospective for the upcoming Sprint. But the team should comply with the rules that define the maximum duration of each event in the Scrum Guide. Moreover, there is another situation that the duration of each event must be changed as mentioned in the previous question.
  • Q: Can the content of Sprint Backlog be modified during the Sprint?
    • A: AgileAlliance has presented its answer when introducing Scrum, which is ‘Once the team and product owner establish the scope of the Sprint as described by the product backlog items no more items can be added to the Sprint Backlog. This protects the team from scope changes within that Sprint‘. But I DO NOT agree. Let’s take a look from the following perspectives.
      • Sprint Goal. This is an objective defined in the Sprint Planning by the Scrum Team that the team MUST satisfy by the development work throughout the Sprint. And the Scrum Guide suggests that ‘The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint‘.
      • Sprint Backlog items. During the Sprint Planning meeting, the selected Product Backlog items are broken down into a set of tasks presenting the HOW of the Sprint Goal met.
    • In conclusion, we can know that one thing must not be changed within the Sprint, which is the Sprint Goal, instead of the scope. And the Sprint Backlog items can be modified during the Sprint to satisfy the Sprint Goal better. There is also some evidence supporting my view in the Scrum Guide, such as ‘Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned‘ and ‘If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint‘.

Remaining Questions

  • Q: Can the Sprint Goal be modified during the Sprint?
  • Q: One of the elements included in the Sprint Review is ‘the development team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved’. Is it more likely to be done during the Sprint Retrospective instead of the Sprint Review?

An Overview of Agile

Definition

No unified definition of Agile.

The term ‘Agile’ was created in a meeting sited by a group of software developers in 2001. They only produced the Manifesto for Agile Software Development, whereas did not explain what ‘Agile’ means. “The only concern with the term agile came from Martin Fowler (a Brit for those who don’t know him) who allowed that most Americans didn’t know how to pronounce the word ‘agile’“, Jim Highsmith noted this interesting story in History: The Agile Manifesto.

As mentioned above, 17 ‘independent thinkers around software development‘ came together to talk, ski, relax and eat on February 11-13, 2001. But after this small conference, they had done a landmark work that found an alternative to the traditional heavyweight, document-driven processes and produced the Agile Manifesto at the end. Today, ‘Agile’ is very broad and is interpreted in the agile community in several different ways. For instances, AgileAlliance defines Agile as ‘the ability to create and respond to change‘; ScrumAlliance suggests that ‘the term agile describes a specific set of foundational principles and values for organizing and managing complex work‘. And as far as I’m concerned, Agile is a set of ideological values that can not only improve productivity but also contribute to a better working environment compared to the traditional development methodology.

On the other hand, I do not agree with some basic views of Agile. For example, the author of The Agile Samurai, Jonathan Rasmusson, presents a definition of agile in website Agile in a Nutshell as ‘Agile is a time-boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end‘. In my view, Agile should not be seen as the Scrum framework (a time-boxed, iterative approach to delivering software), which is just one of the well-known Agile frameworks! Moreover, we can see that there are also many well-known behaviours, concepts and techniques associated with Agile frameworks, while they only can be represented as being part of the Agile way of working, instead of the Agile.

Manifesto

The symbolic output emerged from the meeting and signed by all participants was the Manifesto for Agile Software Development, or the ‘Agile manifesto’ as it is more commonly known. It should be emphasised that the meaning of the final two lines of it is crucial to understand: it is a case of the relative importance of the values, and not a case of ‘good’ or ‘bad’.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over Processes and tools

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Principles

Another output from the meeting was Principles behind the Agile Manifesto. The keywords of each principle have been highlighted in my own mind.

1. Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.

2. Welcoming changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

3. Working software is the primary measure of progress.

4. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

5. Business people and developers must work together daily throughout the project.

6. Build projects around motivated individuals, give them an environment and support they need, and trust them to get the job done.

7. The most efficient and effective method of conveying information to and within a development team is face-to-face communication.

8. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity, the art of maximising the amount of work not done, is essential.

11. The architectures, requirements and designs emerge from self-organising teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adapts its behaviour accordingly.

Features

As presented above, Agile has not been defined in a specific and unified way, while there are many mindset (behaviours or values), concepts (fundamentals) and techniques (practices or tools) that are treated as being part of the Agile way of working. There are some examples of them (obviously, not all of them) shown subsequently as follows.

Mindset (Behaviours)

  • Customer-focused
  • Embracing change
  • Being collaborative
  • Self-organising
  • Empowered
  • Trusting not blaming
  • Respect each other
  • Being confident
  • Empiricism
  • etc.

Concepts

  • Prioritising what is delivered
  • Not delivering everything
  • Communicating continuously and clearly
  • Working iteratively and incrementally
  • Continuous integration
  • Limiting WIP (Work in Progress)
  • Time-focused
  • Inspection and adaptation
  • Kaizen
  • etc.

Techniques

  • Timeboxing
  • Backlogs (Product and Sprint)
  • User stories
  • Planning poker
  • Burn charts
  • CFD (Cumulative Flow Diagram)
  • Retrospectives
  • etc.

Frameworks

It is an interesting fact that some processes, approaches and frameworks focusing on improving iterative and productive capabilities had been created and applied in practice before the term ‘Agile’ created (in 2001), such as XP (eXtreme Programming), Scrum, DSDM (Dynamic Software Development Method), ASD (Adaptive Software Development), Crystal, FDD (Feature-Driven Development), Pragmatic Programming. And actually, Agile was initially introduced by the representatives of these frameworks above, so that they are all included in the family of frameworks being agile basically. Although Agile and most frameworks of it were originally applied in the software development domain, some of them have been recognised as successful frameworks beyond software development nowadays. In addition, there are also some commonly known hybrid approaches having been used in more challenging situations.

There are some typical frameworks in the Agile frameworks family introduced as follows.

widely-used

  • Scrum. The Scrum Guide defines Scrum as ‘a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value‘.
  • Kanban. A method to improve flow and provoke system improvement by visualising the workflow and limiting work in progress.
  • Lean Startup. It is a methodology for the development of businesses and products aimed at shortening lifecycles of product development and discovering the viability of the proposed business model quickly. Lean Startup approach was originally employed for starting up companies, while now is applied to any business.

IT only

  • DevOps. A collaborative approach combining the work and even the teams of software development (Dev) and information-technology operations (Ops), which aims at creating a product or service through shortening the systems development life cycle and providing continuous delivery with high software quality.
  • XP. It stands for eXtreme Programming that is an iterative software development methodology focusing on improving the quality of software products and the capability of responding to the requirement change. XP can be employed solely while commonly used in conjunction with Scrum or Kanban, where XP involves software development and Scrum or Kanban is utilised for the management of work as an overall structure.
  • SAFe. It’s the abbreviation of Scaled Agile Framework. SAFe is an application used to guide the organisation proceed to work with sufficient size or level of difficulty in scaling lean and agile practices.

Hybrid

  • Scrumban. It is an application Kanban where the underlying process is based on Scrum. This combination, a mixture of the structure of Scrum and visualisation of Kanban, enhances the ability to adapt and respond to change without being overburdened.
  • PRINCE2 Agile. PRINCE2 Agile is the world’s most complete agile project management solution, combining the flexibility and responsiveness of agile with the governance of PRINCE2. This approach provides a solution for managing the holistic project process by blending the strengths of PRINCE2 and Agile, that concentrate on the areas of project direction & management and product delivery respectively. It should be noticed that unlike other agile frameworks, PRINCE2 Agile are only suitable for use on projects.

Agile Today

Agile is Trending

Agile has become more popular in software development contexts. “Looking back over the years, it is incredible to see the changes and additions to the report, as Agile adoption has grown and evolved“, CollabNet VersionOne suggests in its blog based on the released 13th Annual State Of Agile Report. The report collected and analysed the information of states of agile from 1,319 responses around the world. It points out that 97% of responses that now use agile are listed in the report. Nonetheless, only 22% of respondents say that their teams are agile, 26% more than half and 48% less than half. One remarkable benefit coming from adopting and implementing Agile is ‘Accelerating software delivery’ (74%). And there are many advantages that can be seen, such as ‘Improving team morale’ (34%), ‘Reducing project risk’ (28%) and ‘Better managing distributed teams’ (19%). The result also indicates that a 71% rise in ‘Reduce project cost’ compared with the previous year is the key explanation for agile adoption.

In regard to the domains beyond software development, Agile has made a significant impact as well. KPMG has released Agile Transformation – 2019 Survey On Agility with responses from more than 120 participants from 17 countries. The survey shows that more organisations are aware of the term Agile according to ‘Agile being scaled with 70% of respondents indicating an ambition to integrate both Business and IT-enabled Agile transformation in the next 3 years‘. Agile is trending!

Agile is Dead

Just like Agile born, when the influence and popularity of a new method continue to rise, it may always bring opposed opinions. These theories against agile are not just derived through theoretical derivation or guessing, but come from the feedback and experience gained by using agile in practice. The tendency of anti-Agile has increased with the influence of Agile. This situation emerged from the birthplace of Agile and has now occurred in many countries and industries. The earliest and the most famous event of anti-Agile is the presentation Agile is DEAD by Dave Thomas, one of the creators of Agile Manifesto. He illustrates that nowadays “Agile” has been defined as the practice of recklessly performing a set of rigid rules and bureaucratic procedures. However, the original Agile means “break all the rules”, while delivering high-quality products, do the most valuable work in a specific environment to achieve the highest production efficiency.

Agile is not what you do.

Agility is how you do it.

And what do you think?

Projects vs. BAU(Business as Usual)

I believe understanding the definition of a project and how to identify it is vitally important before learning project management. The purpose of distinguishing projects and BAU properly is to better manage and control the work in different contexts. More precisely, it could provide a basis for selecting concepts and techniques of management accordingly, and ensure applying them appropriately during executions. For instance, there are limited application contexts for different management methods and frameworks. As mentioned in chapter 1 of PRINCE2 Agile guide[1]: PRINCE2 and PRINCE2 Agile are only suitable for use on projects, whereas agile can be used for projects and routine ongoing work as well”.


PRINCE2 (PRojects IN Controlled Environments): a structured project management method and practitioner certification programme.

PRINCE2 Agile: the world’s most complete agile project management solution, combining the flexibility and responsibility of agile with the governance of PRINCE2.

Definitions

There are no unique definitions of these two practices respectively I could found. In my view, it may be due to the specific environments in the distinct industries which the professionals considered when defined them. However, the interpretations of each of them are comparable in a manner.

BAU

BAU work would typically be repeatable routine tasks that can be carried out by people with the appropriate technical skills without needing to be managed by a project manager“[1].

the normal execution of standard functional operations within an organization – forms a possible contrast to projects or programmes which might introduce change“[2].

The two definitions indicate BAU is a ‘normal’ ‘routine’ work happening almost every business day. Like the common understanding of daily business work, it is executed basically in a fixed process environment which has the major characteristics of repetition, continuity and low risk.

Projects

A project is a temporary situation where a team is assembled to address a specific problem, opportunity or change that is sufficiently difficult that it cannot be handled as BAU. It may even be a collection of BAU items handled collectively“[1].

It’s a temporary endeavor undertaken to create a unique product, service or result“[3].

Compared with BAU, both definitions of projects emphasis ‘temporary’, which means the work of a project is not kind of permanent as BAU. In other words, a project should have its own corresponding and unique lifespan. Moreover, the aim of a project is to generate a ‘thing’ which does not exist in this world before including a concrete manner like a building, or a detailed solution for solving a prescribed requirement. Therefore, the processes of creating unknowns are more comparatively risk and each of them cannot be completely repeated.

Differences

Project

BAU

PRINCE2 Agile guide[1]
  • Temporary
  • Team is created
  • Difficult
  • A degree of uncertainty
  • Ongoing
  • Stable team
  • Routine
  • A degree of certainty
Strategic Project Organising[2]
  • One-off processes / unique
  • Determinate lifecycle
  • Temporary organisation
  • Dynamic staffing
  • Dynamic supply chain
  • Owner/client engages in the process
  • Commercial management
  • Enables change
  • Repetitive processes
  • Indeterminate lifecycle
  • Stable organisation
  • Stable staffing
  • Stable supply chain
  • Process buffered from customer
  • Supply chain management
  • Keeps the business running
Knowledge Train[3]
  • One off/Unique
  • Delivering ‘things’
  • Project manager reporting
  • Start/end time
  • Bring about change
  • More risky
  • Day-to-Day/Repetitive
  • Operational
  • Line manager reporting
  • Ongoing
  • Benefits from change
  • Less risky

The content above lists the differences between projects and BAU from three different and representative sources orderly. According to these, projects and BAU are summarised and re-compared from six new themes, as shown in the following table.

ThemesProjectsBAU
Organisation temporarystable
Costcapitalisedoperational
Timelimitedongoing
Changeenabledidentified
Riskhigh/managedlow/mitigated
Outputcreativerepetitive

The themes consist of:

  1. Organisation. The term ‘organisation’ indicates the execution team, external supply chain and other stakeholders. BAU has a stable supply and demand relationship and its producing process and structure should be fixed enough to achieve routine operation. Regards to projects, as an event responding to satisfy specific needs, the entire organizational structure and interest relationship would be established after the requirements generating. Moreover, this organisation will be disbanded after the value are achieved;
  2. Cost. Projects may generally be capitalized, while typically BAU may not be, due to the fact that the ongoing BAU work is depended on operating expenditures. It means that there are various accounting procedures for projects and other activities.
  3. Time. BAU work has an ongoing lifecycle without a predetermined end date. By contrast, A project is an event that achieves a prescribed purpose within a limited period of time. Hence, determinate time is a crucial characteristic of projects.
  4. Change. Projects and BAU respond differently to change. BAU teams operate existing business processes on a day-to-day basis. And the teams could realise changes and the impact on work as soon as they are implemented. As for a project, as mentioned above, is an event aiming at innovation. Project teams are working to incorporate all of the changes required.
  5. Risk. BAU teams attempt to identify and reduce all the operational risks. They seek to remove uncertainties for more stable and repeatable operation processes. Projects own a risk factor because of their nature of uniqueness and uncertainty. The business is only taking a leap into the unknown by undertaking a project because it implements change and creates something that wasn’t there before. Therefore, in order to reach goals and achieve the best outcomes, the project team sought to reduce the impact of risks by managing them.
  6. Output. This point is not mentioned in the comparison above. However, I believe that output is another major aspect of evaluating an event. It is determined by the goal of the event and the process performed. Projects are one-off event, not repeatable implementing to produce a new ‘thing’ or solution for solving a specific problem, opportunity or change. The output of a project is much more creative than BAU work obviously.

Examples

When I took the first lecture of the course ‘Strategy project Organising’, I was very impressive about that the lecturer asked us introducing some examples of projects and BAU work respectively. I remember a classmate who said at the time that producing a car was a project. But I pointed out that this is not while developing cars is. Now let’s re-evaluate the correctness of my answer based on the six themes summarised above.

For automobile production, it is certain that this is a day-to-day ongoing event in an automobile factory. The supply chain, assembly procedures, and acceptance criteria for each car have been clarified before production commences. This means that the budgets, resources, and output are controlled and stable and its process is repetitive. But for the research and development of new energy vehicles, for example, the reason for the start of this event is to meet the two requirements including people’s living and energy conservation and environmental protection. This is to solve a problem that has just emerged in modern society. Obviously, the traditional automobile manufacturing teams do not have the capability of researching and developing new energy engines and other technologies. Therefore, it is necessary to recruit experts from related fields to form a new research and development team. On the other hand, in order to maximise the benefits of automobile manufacturers, the research and development team needs to use controllable resources to produce feasible and unique solutions within a limited time.

The reason my classmate thought it was a project to produce a car maybe because he draws an analogy between it and building a house. What makes it different is that building a house is not a job that can be done on a unified assembly line with completely identical materials. Due to geographical conditions, construction conditions and other objective factors, the building process is non-repeatable, and the final output is unique.


  1. AXELOS(2018), ‘PRINCE2 Agile Guide’;
  2. R. Paul., Guide to project management : getting it right and achieving lasting benefit (2nd ed.);
  3. PMI, ‘What is Project Management?’;
  4. UoM(2018), ‘Strategy Project Organising’;
  5. Knowledge Train(2013), ‘The difference between projects and business as usual’;