If you’re working in or studying Project Management, becoming familiar with the Agile Manifesto is crucial. Although it is brief and straightforward, its principles have had a huge impact on project management techniques for more than 23 years now.
The manifesto emphasizes core values like individuals and interactions, working software, customer collaboration, and responding to change, which have proven to be effective when working through complex situations. The only trouble is – as human beings we somehow cannot wait to complicate it again.
We add processes, extra names, extra functions, extra job roles, heck we even add extra departments to handle all this extra stuff we’ve added. The core of the Agile Manifesto is being corrupted, because it is actually hard work keeping things simple.
But the simplicity in the Agile Manifesto highlights a key truth: simple approaches often yield the best results, fostering clarity and efficiency in software development and project management.
Just as simple, refactored code is easier to maintain and less prone to errors than complex code, simple designs are more user-friendly and effective than their intricate counterparts. Embracing the simplicity of the Agile Manifesto allows teams to focus on what truly matters, leading to better outcomes. And doing that often leads to greater success and effectiveness, helping you and your team win.
The Secret History of Agile: Unveiling the Roots of a Revolutionary Methodology
The Agile methodology, a transformative approach in software development, is often mistakenly attributed solely to the Agile Manifesto of 2001. However, the roots of Agile stretch much deeper into history, with influences from manufacturing and even early industrial practices. Let’s check out the lesser-known origins of Agile, and see how it has really evolved from the 19th century to today.
The Waterfall Model: A Misunderstood Beginning
The story of Agile cannot be told without mentioning the Waterfall model, traditionally seen as the “enemy” of Agile. Interestingly, Winston Royce, who formalized the Waterfall model, came up with a more iterative and feedback-driven approach in his final notes. Royce emphasized the importance of integrating feedback from testing into design and requirements, advocating for an iterative process and customer involvement.
This philosophy, remarkably similar to Agile, shows that even the origins of the Waterfall model came from principles that Agile later embraced.
Early Industrial Influences: Toyota’s Innovations
Agile’s principles can be traced back to early industrial practices, particularly those pioneered by Toyota. In 1896, Sakichi Toyoda introduced the “Stop and Notify” concept, also known as Jidoka or autonomation. His invention of an automatic loom that halted production if a needle broke was revolutionary, combining human oversight with machine efficiency. This concept of built-in quality control is a cornerstone of Lean manufacturing and, subsequently, Agile.
Post-War Innovation: The Birth of Lean and Kanban
The real transformation began in 1948 when Toyota faced severe resource constraints post-World War II. This led to the creation of the Toyota Production System, the precursor to Lean manufacturing. Lean emphasizes waste reduction and Kaizen, or continuous improvement. From Lean, Kanban emerged, a method of visualizing the work to optimize flow. This later became integral to Agile software development.
The Agile Manifesto: A Culmination of Decades of Ideas
Agile as formally recognized today was crystallized in 2001 with the Agile Manifesto, but its foundations were laid much earlier. The Manifesto was influenced by various methodologies, including Lean, Kanban, Extreme Programming, Feature Driven Development and Scrum. These frameworks collectively contributed to Agile’s emphasis on flexibility, customer collaboration, and iterative development.
Scrum: A Revolutionary Approach
Scrum, often synonymous with Agile, has its roots in a 1986 white paper titled “The New New Product Development Game” by Japanese researchers Hirotaka Takeuchi and Ikujiro Nonaka. They proposed a holistic, team-based approach to product development, likening it to a rugby team working together to move the ball down the field. This approach emphasized overlapping development phases, self-organizing teams, and continuous learning—key principles that underpin Scrum and Agile.
The Six Secrets of The New New Product Development Game
Takeuchi and Nonaka identified six characteristics of successful product development teams, which resonate strongly with Agile principles:
Built-in Instability: Assigning broad goals to capable teams, granting them autonomy and flexibility to meet that goal.
Self-organizing Teams: Teams acting like startups, from ideation to implementation, fostering autonomy, self-transcendence, and cross-functional collaboration (the Product Owner idea in Scrum today).
Overlapping Development Phases: Continuous interaction between research and development and production to ensure constant progress and iteration.
Multi-learning: Encouraging team members to pursue ongoing learning, both within and outside their areas of expertise.
Subtle Control: Implementing visual management and maintaining open workspaces to facilitate communication and collaboration.
Organizational Transfer of Learning: Converting project activities into standard practices to spread knowledge throughout the organization.
As you can see there are many similarities between Scrum as we know it today, and The New New Product Development Game introduced in 1986, even if some of the names are different.
Conclusion: The Ever-Evolving Journey of Agile
The history of Agile is rich and multifaceted, drawing from various disciplines and evolving over decades. From Royce’s iterative vision for Waterfall to Toyota’s Lean principles and the collaborative ethos of Scrum, Agile embodies a continuous pursuit of improvement and adaptability. Understanding this deep and varied history not only enriches our appreciation of Agile but also underscores its enduring relevance in today’s fast-paced, ever-changing technological landscape.
For those eager to dive deeper into Agile’s principles and practices, comprehensive courses and coaching can offer valuable insights and practical skills. Embracing Agile is not just about adopting a methodology; it’s about joining a long-standing tradition of innovation and excellence in product development.
See more PMP Articles and Tips for Passing your Exam:
The three Cs are a great way to remember to collaborate and create items to work on in an Agile team. They stand for the Card, the Conversation and the Confirmation.
The Card
This is the customer requirement, often with "Acceptance Criteria" for what needs to be done. It is written on a card as a User Story, and often shown on a Kanban Board.
The Conversation
A Conversation between: customers or users, developers and testers – our “triad” or “three amigos” – to work through the requirements, solution, and acceptance test criteria.
The Confirmation
Confirmation that the item meets the requirements. The Customer can sign off the requirements, the team can Showcase the increment at the Sprint Review, and the Scrum Master can ensure a Definition of Done is in place for the team.
A Definition of Done is the criteria we have to meet for the card to be seen as "Complete". It might include developing it, testing it, demonstrating it and signing off on it.
Learn Project Management and earn 35 PDUs, Learn Agile and earn 21 PDUs, save yourself 100s of hours with the Excel and PowerPoint templates below.
INVEST is an acronym that helps us when creating user stories. In an Agile team, you’ll typically get together in a “Triad” or “The Three Amigos” of the Customer, Developer and Tester, but it can be anyone who needs to have an input.
INVEST stands for:
Independent, Negotiable, Valuable (or Vertical), Estimable, Small and Testable.
Independent
The User Story should be a usable piece that can operate on its own, independent to others, that we can demonstrate at the end of the Sprint.
Negotiable
The User Story should be able to be negotiated in our out of the sprint, or even out of the Product Backlog if it is no longer valuable. We should be able to negotiate the requirements against the solution.
Valuable
The item should have customer value, and be able to be demonstrated.
Estimable
The item’s effort should be able to be estimated by the team.
Small
It should be small enough to be completed in a Sprint (usually around 2 weeks)
Testable
It should be testable – often the team will write the tests (or acceptance criteria) first using “Test Driven Development”.
Learn Project Management and earn 35 PDUs, Learn Agile and earn 21 PDUs, save yourself 100s of hours with the Excel and PowerPoint templates below.
There are five Scrum values that all project team members, including the project manager (Scrum Master), strive to adhere to on a Scrum project.
Core Value 1 – Commitment
Each team member commits to the team, to each other, and to achieving the goal of each sprint.
Core Value 2 – Focus
The team focuses on the task at hand (avoiding the dangers of multi-tasking) and on the goals of the sprint.
Core Value 3 – Openness
The team is open and transparent – they share information freely and ask for help when they need it.
Core Value 4 – Respect
The team respects each other as capable, independent people.
Core Value 5 – Courage
The team has the courage to do the right thing, work through tough problems, ask for help if needed or say when they don’t know.
The Core Values of a Scrum Team
These core values of Scrum help hold a team together and form a contract (like a Team Charter) that creates a solid foundation as you work together towards your goals.
These are extremely useful to know if you are working on or within a project using Agile or Scrum.
Step 1
The product owner (representing the customer or end user) creates a prioritised list of everything the project might deliver.
This list is called the prioritised product backlog.
Step 2
The team and the Product Owner have a sprint planning meeting. The team decides how much work it can take on in the next sprint.
The team pulls requirements from the prioritized product backlog that it can achieve in the sprint. This work becomes the sprint backlog.
Step 3
The team decides who will do what and creates the task cards in the sprint backlog for the current sprint.
The team will meet each day for a 15-minute meeting, called the daily scrum (also called a stand-up), to share progress updates.
Step 4
The project manager, called the Scrum Master, helps keep the team working toward the sprint goal.
They remove blockers, bring people in to the whole team approach, and facilitate progress.
Step 5
A sprint review happens at the end of each sprint to demonstrate what the team has accomplished to the product owner.
Step 6
After the sprint review the team participates in a sprint retrospective to discuss what did or did not work in the last sprint.
This gives the Scrum Master and the team an opportunity to adjust the processes and work for the next sprint.
Step 7
The whole process repeats itself by the project team selecting the next chunk of prioritized requirements from the backlog and getting to work in the next sprint.
Implementing Scrum
Implementing Scrum in an organization can be tricky, especially if no one in the organisation or team have done it before.
Show the value of Scrum through the results you get by using it, and more and more people will be interested in adopting the Scrum approach.
This is the Agile Practice Guide from the Project Management Institute and Agile Alliance, and this particular one is delivering in an Agile environment.
Check out the video and article below!
Delivering in an Agile Environment
There are two things in focus when delivering in an Agile environment, and the first is the team and the project charter. The second is the way we measure results – it can be very different than that of a traditional approach when we’re using Agile. First let’s look at the Charter.
Charter the Project and the Team
Usually in a traditional approach using the project management body of knowledge, which goes through very set steps that will initiate a project with a project charter. It will go through what the project stands for, what the risks are, who the stakeholders are, all those things. It will initiate that project and kick it off.
Now in addition to that when we’re using an Agile approach, our cross-functional team will initiate with a team Charter. What that means is you’ve seen the cross-functional team before where we’ve got the roles like the facilitator, we’ve got the product owner, and they represent the customer or the business. And then we’ve got our cross-functional team members who are those T-shaped members who have a general knowledge of a lot of things and then one really deep specialty knowledge. So these team members are extremely valuable because they might have one deep specialty of development and then many many general knowledge areas such as design or testing or or even leadership. All of those different things.
Our team Charter includes the project vision or the purpose, and this is so important and it’s so wonderful as well. Why? Because we want to start with “why”. Start with why is a classic book by Simon Sinek, and it’s just a wonderful way to get everyone on the same page and make sure everyone is heading in the right direction. “Why” is it that we are doing this in the first place?
Once we’ve got that, we work on a clear set of working agreements and that can involve many different things. When we were working on the purpose and the why we ask the questions “why are we doing this project, who benefits from this project,” and what does done mean for this project? What is the definition of done, when do we finish working? And then how are we going to work together. Now the best role and this can be anyone who has this leadership quality is the Servant Leader, who may facilitate that chartering process sitting down with the team, facilitating everyone, getting them working together and extracting that information from the team.
So they can put it down into words where it may have been hidden before. The servant leader’s role is also to help coach and to help remove blockers.
Now the team charter is also a social contract. That social contract can include things like team values, such as the sustainable pace and the core hours. We’ve talked about the sustainable pace before – we don’t want people to be working the midnight shift and then crashing and burning the next day. Or really going crazy one week and then having three days off sick – it’s just not sustainable, and it’s not a great way to work. From an Agile perspective we want that sustainable pace, and we want to put that down in words. What is that sustainable pace? Do we have set breaks, do we have set hours, what are our core hours, are they late or are they early, does everyone get in at the same time? All of those things, let’s write it down.
We have working agreements such as what “ready” means, so the team can take in work. So when are you ready to take in more work? What done means – so when are you finished that work? And the team can judge that completeness consistently.
Respecting the time box – so they are iterations of two to four weeks, and their work in progress limits. If the team is working in an Agile format where they’ve got cards and maybe they have limits for how many cards they can take on at a time, you don’t want all of your cards sitting in the backlog of work, but likewise you need to make sure that everyone understands when they can take on a new piece of work as well. And that goes in the team charter.
We want ground rules, such as one person talking in a meeting at a time. Or maybe you want a lot of discussion, a lot of collaboration at a time and maybe everyone agrees with that. And we want group norms such as how the team treats meeting times – is everyone on time? Or can someone miss it if they’ve got something really important on? What are those rules and does everyone agree?
Of course you can put any other behavior that the team wants to work with or address. Maybe something has bugged someone in a previous working arrangement and they just want to bring it up and they want to say – “Hey this didn’t work well the last time or maybe this worked really well,” and they want to bring this up and that can go in the team charter
as well.
How Agile Teams Measure Results
As we’re delivering in an Agile environment, Agile teams measure things quite differently to that of a normal project. The way they do that is that they actually measure results in the way that the project is delivered in other words the pieces of the project that are delivered, the functional pieces.
Agile favors value-based measurements, and that’s value from the perspective of our customer. So what are the valuable pieces that our customer can get their hands on and use, and how many of those pieces have we delivered? Instead of normal predictive measurements like Earned Value Management or Schedule Management or cost management that we could use in a more traditional waterfall approach, by measuring what is done and re-planning at each iteration by iteration there’s less room for error and more room to correct course.
And we’ll see that in the way that we measure those results with a burn-up chart or a burndown chart, and these burn up charts or burndown charts are basically these story points remaining. As you can see we might have features and then often many smaller “stories” will make up those features. And features can make up larger increments that we’re delivering to a customer.
The pieces of work that we’re working on as a team – maybe we have a thousand stories altogether in the in the product backlog and then per iteration we might have 20 or 30 or 50, but each time one of those stories is finished we’re marking it off on the chart, so we’re basically counting down the number of stories that we have completed. We want to aim for a certain amount of stories so as you can see here over 10 iterations we’re wanting to
finish that amount of stories but in reality sometimes it is a little bit different. So we can give ourselves a guide but obviously when it’s happening it might fluctuate – it might go up and down or not go at the exact pace that we want it to, because life happens and things get in the way.
So by making it visual and by measuring by the story points and the features that we’re releasing and the things that are getting done and the value that we’re adding to the customer – that is the way that an Agile team will measure results.
Want to learn about Lean? Get the book "Five Minute Lean", by David McLachlan - a wonderful book that blends teaching of the tools, culture and philosophy of traditional Lean with a modern-day Lean parable.
You can get the whole book on Amazon here and enjoy your own copy.
We’re looking at the Agile and Lean frameworks from the Agile Practice Guide, by the Project Management Institute and Agile Alliance. There are core frameworks and auxiliary frameworks that you will come across on your Agile journey. Depending on the organization or the team that you work in, usually someone will be using some of these methods. You don’t have to use all of them, as often many of them have the same core practices underneath such as visual management, daily stand-ups, having a product owner, and grooming a backlog.
It’s really useful to know the actual frameworks and the names that
people might be using to refer to them, just so that you can keep up with the conversation and also understand what’s happening underneath – the underlying principles behind these methodologies. This one we’re going to look at involves Scaling Agile methodologies. We’ve got Scrum of Scrums, the Scaled Agile Framework, we’ve got Disciplined Agile, and we’ve got Large-Scale Scrum.
Check out the video and the article below!
Scrum of Scrums
With Scrum of Scrums, it is similar to Projects, Programs and Portfolios. If you’ve worked in project management you’ll know that we’ve got portfolios at the high level, then we’ve got programs underneath that, and we have a number of projects underneath that. It’s just a really high-level approach to managing a portfolio of work.
Scrum of Scrums is conducted when we’ve got two or more teams, usually of three to nine people (most often in a scrum team we’ve got three to nine people so it’s not too big but also not too small) and we’re needing to coordinate all of the work across those teams. A representative from each team will attend a meeting with other team representatives around three times a week. This is very similar to the daily standup but not quite – it’s just a method of keeping everyone on the same page across streams. That representative from the team will attend the meeting with the other representatives from their teams three times a week to report on their completed work, their next set of work, any current blockers in their work and potential upcoming blockers.
This is a really good practice and it’s good to see what other teams are doing. Keeping that
communication line open is important when you’ve got multiple streams of work all working towards similar dates or similar deliverables. The goal is to ensure that our teams are coordinating their work and removing blockers across teams, not just within the team itself.
The way it looks is you’ve got your Scrum teams of between three to nine people. You might have multiple Scrum teams so then one of these representatives will come and report to the Scrum of Scrums meeting three times a week. Then once a week we’ve got the Scrum of Scrum of Scrums – similar to that portfolio level.
Scaled Agile Framework (SAFe)
As part of our Scaling Agile frameworks we’ve also got the Scaled Agile Framework, or SAFe. SAFe basically helps with detailing practices, roles and activities at the portfolio, the program and the project levels, similar to our scrum of scrums.
It focuses on organizing the enterprise around value streams, that provide value to the
customer. We’re focusing on the customer’s point of view. These programs that we’ve got and the projects within them provide this particular piece of value and it’s basically with the end customer in mind, so everything is all organized around that value to the customer.
The principles are to take an economic view, to apply systems thinking (so to understand that this small piece in the system will affect the bigger cog in a system will and so on), in other words nothing is done in isolation and we always think about the consequences of even the smallest actions. Assume variability and preserve options, building incrementally with fast integrated learning cycles.
Does that sound familiar? That’s definitely an Agile principle – we’ve got our iterative approach, we’ve got our incremental approach, all of these things help us get stuff into the
hands of our customers quickly.
We want to base milestones on objective evaluation of working systems. This is Continuous Integration where we’ve got all of our changes going up into the one
environment so we can see whether it’s working or not, and we can see that on a daily
basis.
We want to visualize and limit the work-in-progress, reduce batch sizes, and manage queue lengths. Now that will be familiar to you as well with the visual management approach of Kanban. We’ve got the Kanban board and we can clearly see the work and whether it’s flowing through the the value chain, or our team value chain, from the backlog on the
left to done on the right. We can clearly see whether it’s flowing or whether it’s stuck.
We want to apply this cadence for synchronizing with cross-domain planning, and that is where our scrum of scrums will come into it. So now we’re planning with other teams and we’re helping other teams remove blockers, and we’re making sure that we know what’s
happening across streams as well.
We want to unlock the intrinsic motivation of knowledge workers. This is something that I haven’t seen mentioned in any other part of Agile, but it really is a core part of Agile. In fact the all of the practices that we perform as an Agile team and their core methods will actually help unlock that intrinsic motivation. That’s where you’re motivated internally as opposed to just motivated by money or a bonus or something similar like that. We’ve got things like checking in with with our team and making sure that everything is really clear, helping bring meaning to the work by making sure the work is connected to the customer. All of those things really help with the intrinsic motivation.
We’ve got decentralizing the decision making, and that comes across with our whole team approach where we have all the people involved, not just you know one person or one team.
Large Scale Scrum (LeSS)
As part of our scaled Agile frameworks we’ve got Large Scale Scrum, also known as LeSS. LeSS aims to organize several development teams towards a common goal by extending the Scrum method across teams, similar to scrum of scrums.
Because of that you’ll see some similarities between LeSS and Scrum and some LeSS techniques have been added to scrum. These similarities we’ve got one single product backlog, we’ve got one definition of done for all teams so everyone is on the same page. We’ve got one potentially shippable product increment at the end of each sprint (and we’ve touched on that many times we’ve got a sprint of two to four weeks and we’re showcasing an increment to the customer at the end of that so that they can see whether we’re on the right track or not and that’s our potentially shippable product)
We’ve got one product owner, who is someone representing the customer. We’ve got complete cross-functional teams – that’s our T-shaped person, our generalizing specialists with one specialty area and many general knowledge areas.
We’ve got one sprint and sprint planning is more formally divided into two parts of what
and how.
We’ve got organic cross team coordination, we’ve got overall cross team refinement (an overall retrospective focused on cross team improvements). This is where we take all of those normal scrum methodologies and we apply them across all teams. For example that retrospective where we can get all of our teams together and say what’s working well
across our teams, not just within the one scrum team itself.
Enterprise Scrum
Enterprise scrum is a framework designed to apply the Scrum method at an organizational level, not just at a single product development effort.
It advises leaders to extend the use of scrum across all aspects of the organization and to generalize the scrum techniques to apply easily at those various levels. We are wanting to scale the scrum method with supplemental techniques as necessary – core principles like stand-ups, retrospectives, Kanban boards and visual management, having iterations and
increments and all of those things.
In other words we’re not precious about which scrum techniques we’re using, but we can add to them whatever we feel works for our teams as long as it helps us scale that method across teams.
Disciplined Agile
Lastly for our scalable methods we’ve got Disciplined Agile. DA is a process decision framework that blends various Agile techniques based on the following principles:
People-first
Learning oriented where we’re encouraging collaborative improvement,
Full delivery lifecycle, where we’re promoting fit for purpose life cycles
Goal driven, where we’re tailoring processes to achieve specific outcomes so we’re looking at results over the process – that’s one of the core things you’ll see in Agile come back time and time again.
Enterprise awareness, where we’re offering guidance on cross departmental
governance. That means we’re still managing across teams whether it’s by
any of these scalable techniques that we’ve seen or just a scalable scrum
technique that seems to be really the core common denominator across all of
these scalable techniques.
Lastly, Scalable, covering multiple dimensions of program complexity and doing that in such a way so using the Agile techniques where we’ve got Visual management across streams and Scrum or stand-ups across teams
All that can help us scale this this approach and help all of our teams work together.
And those are the auxiliary methods and the scalable methods of Agile.
Want to learn about Lean? Get the book "Five Minute Lean", by David McLachlan - a wonderful book that blends teaching of the tools, culture and philosophy of traditional Lean with a modern-day Lean parable.
You can get the whole book on Amazon here and enjoy your own copy.
We’re looking at the Agile Practice Guide from the Project Management Institute and Agile Alliance. This one in particular is “Evolving the organization.”
Check out the article and video below!
Evolving the Organisation
When we say evolving the organization, really what we’re talking about is bringing Agile into an organization in a way that also uses the Agile methodology. Maybe traditionally you’ve been using a more linear approach, very step-by-step, very focused and figuring out all the scope and cost upfront, and then being afraid when all that changes as the project rolls out.
But if we’re moving towards more of an Agile approach it’s really recommended that we undertake that work incrementally. In other words we’re actually using Agile, and our Agile way of putting things in the hands of our customers (which in this case is our teammates and our organization) then we’re using that to actually roll it out so we treat the change as an Agile project with its own backlog of work, and backlog of changes or Agile things that we could implement and that could be introduced to the team, based on the perceived value.
In this case our team is the customer so whether you’re leading a team or maybe you’re trying to implement it across an organization, but either way the customer in this case is other people who you’re moving the implementation of Agile onto. That means that the value has to be based on what they perceive the value to be, and that’s very important.
Iterating Towards Agile
When we’re iterating and getting that feedback from the customer as we’re implementing Agile, then we’re putting that feedback back into the process and using what works and discarding and what doesn’t. So when we are are implementing practices like Scrum or Kanban or Feature Driven Development, or maybe Scrum of Scrums across multiple teams, or many other things like the whole team approach and regular feedback using iterations – each of those changes can be treated as an experiment. They can be tested for a short period of time to determine the suitability or need, or to further refine it.
What that means is we don’t have to say “Look everyone, this is happening!” We can instead say “Let’s try it out for one or two iterations,” in this case using Agile terminology again, say four to eight weeks in total, and then let’s round back on it using a Retrospective where we ask is this working well, what didn’t work well, what did I learn and what still puzzles me during this implementation.
Then we can put that feedback back into the process.
Using the Agile Method of Kanban to Track Progress
We can also use Kanban boards to track the progress of the things that we’re implementing – showing the new approaches to use as “done” and the things that we’ve tried as or we’re currently trying as in progress. Again this is another Agile approach. We’ve got all of these things that we want to implement in the backlog – maybe we’re going to move to Scrum, maybe we’re going to use Kanban, maybe we’re going to use the Whole Team Approach or a cross-functional team and some of those will be moving those across into “in progress” and some of those will already be finished.
Assessing the Current Culture
We’ll have gone through that retrospective process to find out what worked, what didn’t work, what we want to keep and what we want to discard. Now before we get into all of this or to start implementing these changes we can assess the current culture and its readiness for a job and tailor a solution to suit.
As we’ve seen there are quite a few different methods and practices that we can use in Agile and not all organizations will want to use all of those practices. One model that we can use to find out what would suit an organization is where we ask:
Do we value exploration more than execution for example, maybe we really really just need to deliver things and we need to deliver things quickly and in that case maybe we can increment and deliver increments every two to four weeks on a regular basis. Or maybe we want speed or maybe we’ll want stability in the team. Which one is more valuable?
Maybe we want quantity maybe we want quality. And maybe want flexibility in our work or maybe want predictability in our work. This will just help us determine which of the Agile practices will be valuable from a team’s perspective. You could use any framework really when you’re figuring this out and what to use from an Agile perspective but the key point is that we want to be understanding the team. Whether it’s just going and talking to the team and saying “Hey what are you currently doing, would this work, can we use it as a test?” and we then get feedback on it, let’s work together. The whole point is delivering value from the perspective of your customer, and in this case the customer is the team.
And that is evolving the organization from an Agile perspective.
Want to learn about Lean? Get the book "Five Minute Lean", by David McLachlan - a wonderful book that blends teaching of the tools, culture and philosophy of traditional Lean with a modern-day Lean parable.
You can get the whole book on Amazon here and enjoy your own copy.
We’re looking at the Agile and Lean frameworks from the Agile Practice Guide from the Project Management Institute and Agile Alliance.
We’re looking at this because as you go along your Agile journey, you’ll find many core methods, and people may call themselves an Agile team and use only one or two of these methods. That’s often fine as long as we’ve got the core Agile practices as part of that – things such as the whole team approach, daily doing stand-ups, retrospectives. Many teams will have some of these core methods and sometimes even some of these auxiliary methods that they’re practicing as an Agile team or an Agile company.
This one we’re going to look at is the Agile auxiliary methods of Agile Unified Process, DSDM or Dynamic Systems Delivery Method, and Behavior-Driven Development.
Check out the video and article below, now!
Dynamic Systems Delivery Method
Dynamic Systems Delivery Method or DSDM was designed to add more rigor to the rising iterative methods of the 1990s. It’s most known for its emphasis on constraint-driven delivery, which sets Cost, Quality and Time in the beginning and then uses formalized prioritization of scope to meet those constraints. In other words, it’s meeting up with the Agile approach of having fixed time, where we’ve got our fixed time boxes of two to four weeks depending on what your team has arranged or has agreed on and then a set time frame for delivering the product. The cost might be fixed as well, and the quality – we always want high quality and that needs to be fixed within an Agile team. However, we can adjust the scope as we go along. And as we iterate with our product, yes, sometimes that product will change and the requirements might change when a customer sees it and just has a little bit of feedback based on what we’ve been developing.
Eight principles guide the use of DSDM. We focus on the business need, and there are many different ways of doing this within Agile. The product owner represents the customer, and we’ve got reviews of the product every two to four weeks so the customer can see, feel and touch it and make sure that we’re on the right track.
We’ve got delivering on time, collaboration, never compromising quality, and building incrementally from firm foundations. We’re making sure that we understand what the main feature and the main product is going to be, as part of our feature-driven development (that you might recognise) and then building incrementally – building those features out from those firm foundations.
We’ve got developing iteratively. So making sure our customer can see it by performing those reviews at the end of our iteration. This means a customer can see what’s going on and make sure that we’re on the right track and adjust if necessary.
We’ve got communicating continuously and early – that’s part of our daily stand-ups that you might recognize, and we’ve got demonstrating. control, using the appropriate techniques and prioritization of scope.
We’re making sure that the product owner is involved and making sure the customer is involved in prioritizing the scope that they want to see, and we develop what’s most valuable to them.
Next, we’ve got Agile Unified Process or AUP as well. The intent of AUP is to perform Iterative Cycles across seven key disciplines and incorporate the associated feedback before formal delivery. So someone using AUP will have these disciplines within a release:
We’ve got the model implementation, testing deployment, configuration management, project management, and the environment. All of these are the disciplines of AUP.
But the principles guiding those disciplines are: we want to make sure that the team understands and has clarity and knows what it’s doing. We want simplicity with what the team is doing- so we don’t want complex things just for the sake of doing that. We want agility – so the ability to adjust and change quickly if needed. Focusing on high-value activities, of course we’ve seen that many times with the Product Owner getting involved prioritizing that backlog of the highest value activities for the customer. We’ve got tool independence, so things can function on their own if necessary – if one item goes down, it doesn’t bring the whole thing down. We’ve got tailoring to fit and situationally specific.
Lastly, we’ve also got Behavior-Driven Development as one of our auxiliary methods to Agile. This is another simple way of defining these stories or the features from the Customer’s point of view, and it’s a great way to define those when you’re performing collaborative user story creation. So when the whole team is getting together, creating that user story based on all the different inputs from the tester, the developer, the designer, the product owner, we make sure everyone has an input into that so that it’s a wholly created card from the customer’s point of view.
With BDD, we’ve got “Given” some initial context, “When” an event occurs, “Then” ensure some outcomes. So given this system is in this mode, when this happens then we want that to happen. And that’s just a nice way to describe it so everyone is on the same page.
Those are some more of the auxiliary methods of the Agile and lean frameworks.
Want to learn about Lean? Get the book "Five Minute Lean", by David McLachlan - a wonderful book that blends teaching of the tools, culture and philosophy of traditional Lean with a modern-day Lean parable.
You can get the whole book on Amazon here and enjoy your own copy.
A Simple Manifesto for Complicated Humans
The Secret History of Agile: Unveiling the Roots of a Revolutionary Methodology
