Tag Archives: agile

Auxiliary Agile Frameworks – Dynamic Systems Delivery Method, Agile Unified Process, Behavior Driven Development

Agile, , , , , , ,

– Back to the Agile Practice Guide (all) –

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.

Agile Framework DSDM Constraints

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.

– David McLachlan

– Back to the Agile Practice Guide (all) –

Get the Leadership Card Deck or the Five Minute Lean Book:

Leadership CardsView All The Leadership Cards (48)

- or - Have the Leadership Cards delivered for your next meeting

 

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.

Crystal – The Agile Practice Guide

Agile, , , , ,

– Back to the Agile Practice Guide (all) –

These are the Agile and Lean frameworks from the Agile Practice Guide, from the Project Management Institute and Agile Alliance.

We’ve already looked at the core methods involving Scrum, Kanban, eXtreme Programming and Feature Driven Development, and these are frameworks you’ll usually find at least one of in an Agile team.

But there are many auxiliary methods to Agile as well, and some of these will be scalable methods to scale across an enterprise or an organization, not just within one team. It can now be across business teams as well.

Now we’re going to look at Crystal as part of our auxiliary methods.

The Agile Framework of Crystal

Crystal was introduced by Alistair Cockburn in his book “Crystal Clear”, and it was created at IBM in 1991, long before the term Agile was even imagined. Crystal is an Agile framework now, and it’s focusing on individuals and their interactions. This is one of the core Agile principles, and doing this is opposed to (or more than) “processes and tools”. This is the first agile principle.

As it notes it is not a set process but it’s more of a guideline for team collaboration and communication. We’ve got three core beliefs – firstly:

Technologies change techniques.
As you’ve seen, depending on what technology you’re working on or what product you’re developing you may need to adjust the technique that you’re using to develop that.

Cultures change norms.
The culture of an organization will have an effect on the norms that you have within your team.

Distances change communication.
That’s why in an Agile team we recommend the “whole team approach” – all co-located in the one place so you can just look over your shoulder and say “hey Joe, can you help me with this?” instead of sending an email or making a telephone call and not getting a reply.

Crystal is designed to scale and it realizes that each project may require a slightly tailored set of practices based on its size and its complexity. It has a few core values and a few common properties. From a Crystal point of view its core values are focusing on people their interactions, the community, their skill sets, talents and communications.

Then the common properties are frequent delivery (very traditional for Agile), reflective improvement (think of your retrospectives – asking what went well, what didn’t go well, what still puzzles me, and what have I learned?) and putting that back into the process, improving every iteration of two to four weeks.

We’ve got close communication, so that’s the whole team approach – everyone in the same place, nice and easy. Personal safety, when you feel safe as a team it’s much easier to be to be honest about what’s going on and to make honest responses to the product or to the development cycle. It’s much easier to improve as well.

We’ve got focus and easy access to expert users – usually through the Product Owner from the whole team approach, someone who represents the customer or the customer themselves. We’ve got technical environment with automated tests, configuration management and frequent integration – that’s our continuous integration core practice within Agile as well.

So you can see why all of these things match up so closely with Agile and fit with it so well, even though it may not necessarily be one of the most core practices, its methodologies definitely are part of the core methodologies.

But Crystal is also designed to scale. We realize that each project may require a slightly tailored set of practices, and this is what it means. We’ve got the sizing framework within Crystal and it’s based on a few things – the life of the project, the money of the project, discretionary money and the comfort level of the project, and then the number of people involved. So maybe we’ve got only one to four people it’s nice and small, maybe there’s a lower level of money involved, maybe it’s a short project life cycle as well this is Crystal Clear. As you can see, it goes all the way up to Crystal Red just depending on the sizing of all of these things – the people, the money, the comfort level and the number of people involved and based on those you can size and scale up the Agile approaches. We’ll see we’ve got things like Scrum of Scrums and many other scaling frameworks that can be used in larger projects or scenarios.

And that is the Agile auxiliary method of Crystal.

– David McLachlan

– Back to the Agile Practice Guide (all) –

Get the Leadership Card Deck or the Five Minute Lean Book:

Leadership CardsView All The Leadership Cards (48)

- or - Have the Leadership Cards delivered for your next meeting

 

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.

Feature Driven Development – The Agile Practice Guide

Agile, ,

– Back to the Agile Practice Guide (all) –

We’re looking at the Agile and Lean frameworks, from the Agile Practice Guide, by the Project Management Institute and Agile Alliance.

As you go along your Agile journey you’ll notice that there are many different methods that people will use, and they might be calling “Agile” many different things. Usually those methods will be some form of these core methods, and maybe some part of these auxiliary methods, but definitely all of the practices that we’ve looked at like standups, iterations, using visual management.  This is a good way to understand what they are, and a little bit of background so you can tell if a team is truly Agile or not.  This one we’re going to look at is Feature Driven Development.

The Core Agile Framework of Feature Driven Development

Feature Driven Development is an iterative model for developing software, or it could be for developing a product. With any project, when developing a product for a customer it should add value for the customer. So it could be software or it could actually be a product as well.

It focuses on developing an overall model, building a features list, then planning by those features, designing by those features and ultimately building by those features.

So from left to right we’re:

  • Developing the high-level model of what we’re looking for and what we’re going to develop.
  • Then we develop the features list, so how would we support that here at the overall view of what we’re wanting to do. What features will we develop?
  • Then we plan by those features – for example how are we going to get it done?
  • Then we design by those features – so we design the overall product by those individual features. We build those features and then we get the feedback.

As you can see in an Agile approach we’re always getting feedback, using iterations of two to four weeks, showcasing to the customer and then putting that feedback back into the product so that we know whether they’re happy or not. When we get that feedback we go back to the beginning and we adjust the high-level model perhaps, and then we adjust the features that we might need to be building, adjust the planning that we might need to be planning for our features, and the design and so on.

This is a core framework of Agile because with Feature Driven Development we’re always developing increments, or features to showcase to our customer.  Everything is designed with showcasing that feature to a customer so they can tell us if it’s what they expected or not, and we can adjust if we need to.  The feature driven development activities are supported by a core set of software engineering best practices as well, and these can apply to a product or a business-side team if you like.  We’re developing by feature, as we saw with using feature teams so a team will focus on a specific feature.  We’re showing that to the customer and asking are we on the right track, are we not on the right track?  And we’re usually doing that at the end of our iterations of two to four weeks.

We’re implementing regular builds – that’s our continuous integration policy where we’ve got all of our changes, and we’re putting all those changes up into the one environment and then we’re usually testing that, so we’re seeing if something has broken or not. And we’re doing that regularly so we know that everything is going well or not going well.

We’ve got visibility of progress and results – we’ve seen that in our Kanban board and our visual management.

Configuration management, individual class ownership, and domain object modeling, and those are your more software owns in terms but the ones at the top here will definitely apply to any project or any business side team as well as software.

And that is the core Agile framework of Feature Driven Development.

– David McLachlan

– Back to the Agile Practice Guide (all) –

Get the Leadership Card Deck or the Five Minute Lean Book:

Leadership CardsView All The Leadership Cards (48)

- or - Have the Leadership Cards delivered for your next meeting

 

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.

XP (eXtreme Programming) – The Agile Practice Guide

Agile, , ,

– Back to the Agile Practice Guide (all) –

We’re looking at the Agile and Lean frameworks from the Agile Practice Guide, by the Project Management Institute and Agile Alliance.

The reason we’re looking at these is because as you go along your Agile journey there are many different Agile methods that you’ll come across and that people may be using, or may not be using, or maybe partially using.  And there are also many Auxiliary methods and even scalable methods that you’ll find within Agile where people are calling themselves Agile and using one or some of these methods, and it’s just nice to know what they are, a little bit behind them, how they match up with the core practices of Agile so you can really tell if that team is genuinely Agile or not.

The next one we’re looking at is XP or Extreme Programming.

The Core Agile Framework of XP

XP or extreme programming is a software development method based on frequent cycles. So already we can see a core Agile practice, having frequent cycles or iterations.  XP is known for popularizing a holistic set of twelve primary practices, and these later expanded into other secondary practices as well.  The reason why this has become a core Agile framework is because you’ll see many of the Extreme Programming principles as part of the core Agile practices as well.  For example frequent cycles, sitting together with the whole team, testing first, all of those things that we’ve been through.

Continue reading XP (eXtreme Programming) – The Agile Practice Guide →

Kanban – The Agile Practice Guide

Agile, , ,

– Back to the Agile Practice Guide (all) –

We’re looking at the Agile and Lean frameworks from the Agile Practice Guide, by the Project Management Institute and Agile Alliance.

The reason we’re looking at these is because there are many different methods that you’ll come across in your organization on your Agile journey, and there are many core methods that you’ll come across and also many auxiliary methods that you’ll come across as well. It’s important to know what they are, and a little bit behind them so you can match them up to the core methods and see whether a team is truly Agile or not. This one in particular is Kanban.

The Core Agile Framework of Kanban

Kanban translates to “visual sign” or “card” in Japanese. It has come from the Toyota Production System so it’s got decades and decades of proof behind it in a production environment, and now it’s found its way into technology and project management and even enterprise management as well.

It’s a form of visual management, and it comes from Lean manufacturing for monitoring the Work In Progress. It enables “Pull” and “Flow”, which are two key Lean concepts. The Lean concept of Pull means that we pull the work when we’re ready, so we never have too much work on our plate – we’re never overburdened.  It was traditionally used for inventory, so we would never have too much inventory (which is basically money just sitting there in a manufacturing plant, in a business sense) but it’s the same for technology.

Continue reading Kanban – The Agile Practice Guide →

Scrum – The Agile Practice Guide

Agile, , , ,

– Back to the Agile Practice Guide (all) –

We’re looking at the Agile and Lean frameworks from the Agile Practice Guide, from the Project Management Institute and Agile Alliance.

What you’ll find is that there are many different Agile and Lean frameworks and ways of describing what are essentially very similar Agile practices. We’ve already looked at the core Agile practices and traditionally you could call yourself an Agile practitioner if you were doing those Agile practices, no matter what framework you were using in an organization. That’s why it’s important to understand what’s underneath these frameworks, and also the names of the frameworks that you might come across in your day-to-day work as an Agile practitioner.

There are a handful of core methods that you’ll definitely see in almost every Agile way of work, and then many auxiliary methods and even “scalable” methods because Agile has made its way out of software development, out of production in general and into the broader organization, into the Project Management Office and across the Enterprise as well. So we’re going to start with the core methods and the first one we’re going to look at is Scrum.

The Core Agile Framework of Scrum

Scrum is a single team framework for managing product development. In a project, we’re creating a product for a customer – something that delivers value for our customer. Now, we’ve already looked at this in the core Agile practice of the whole team approach, where it really matches up to what a scrum team consists of.

First we’ve got the Product Owner. The Product Owner represents the customer – they are responsible for maximizing the value of the product. The Product Owner represents the customer or represents the business and they help “groom the backlog of work” through the user stories, usually on a Kanban board (which we will see as well). In other words they put that work, in the form of user stories, into prioritization.

Continue reading Scrum – The Agile Practice Guide →

Demonstrations and Reviews – The Agile Practice Guide

Agile, , , , ,

– Back to the Agile Practice Guide (all) –

The Agile Core Practices

There are certain core Agile practices you might be doing as a team – and not necessarily calling yourself Agile or using the framework names, but still working in an Agile way. Knowing these core practices is a great way to get a deeper understanding of Agile as an approach.

One of the best places to update your skills in Agile is from the Agile Practice Guide, by the Project Management Institute and Agile Alliance. This one in particular is demonstrations and reviews.

Check out the video and article below!

Demonstrations and Reviews

As part of gathering early feedback, the team will complete features in the form of user stories. The team periodically demonstrates that work – the working product or the pieces that they’ve created – they demonstrate that to the customer or to the business or the product owner (remembering that the Product Owner in in the Agile Whole Team Approach represents the customer and the business).

So you could be demonstrating it to the Product Owner and they could relay that information, but usually it is best to go straight to the source and demonstrate your working increment to the customer or to the business who is ultimately getting the value that you’re creating.

Often this occurs at the end of an iteration of around two weeks to four weeks or when enough of those features have been completed into a set that’s coherent. For example maybe it takes a few of these features to be to be created to have something that a customer can see, feel and touch, and that you can actually demonstrate to a customer.

We demonstrate this increment or usable set of features so that we can start getting feedback on that increment. Team members can also get feedback that prevents them from heading in the wrong direction by using this approach, and that’s why it’s so valuable.

And that is Agile demonstrations and reviews.

– David McLachlan

– Back to the Agile Practice Guide (all) –

Get the Leadership Card Deck or the Five Minute Lean Book:

Leadership CardsView All The Leadership Cards (48)

- or - Have the Leadership Cards delivered for your next meeting

 

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.

Continuous Integration – The Agile Practice Guide

Agile,

– Back to the Agile Practice Guide (all) –

The Agile Core Practices

There are certain core Agile practices within Agile that can be used regardless of whether you call yourself an Agile team or not.  Knowing these core practices is also a great way to get a deeper understanding of Agile as an approach.

One of the best places to update your skills in Agile is from the Agile Practice Guide, by the Project Management Institute and Agile Alliance. This one in particular is Continuous Integration and other execution practices.

Check it out!

Continuous Integration and other execution practices

As we’ve seen, Agile is the combination of an iterative approach – where we’re iterating and improving our product – and also an incremental approach where we’re delivering something at the end of those iterations.

Continue reading Continuous Integration – The Agile Practice Guide →

Collaborative User Story Creation – The Agile Practice Guide

Agile, ,

– Back to the Agile Practice Guide (all) –

The Agile Core Practices

There are certain core Agile practices you might be doing as a team – and not necessarily calling yourself Agile or using the framework names, but still working in an Agile way. Knowing these core practices is a great way to get a deeper understanding of Agile as an approach.

One of the best places to update your skills in Agile is from the Agile Practice Guide, by the Project Management Institute and Agile Alliance. This one in particular is collaborative user story creation.

Collaborative User Story Creation

With collaborative user story creation, it’s important because poor specifications are usually a major reason for project failure. We may have specified what the customer wants, and then when they actually get their hands on it they may actually have wanted something different. Or we may have misinterpreted what they wanted in the first place. Al of this results in them not really being happy with the end result. So poor specifications are often that major reason for project failure.

In Agile development, user stories are written with with a lot of the people involved, from the customers through to the people creating the product. We’ve got the developers who are developing our product, testers, business representatives or the product owner in the whole team approach. We have frequent informal reviews of the things that they’re creating just to make sure that they’re right, and everyone who needs to be is always involved.

Continue reading Collaborative User Story Creation – The Agile Practice Guide →

Release and Iteration Planning – The Agile Practice Guide

Agile, , , ,

– Back to the Agile Practice Guide (all) –

The Agile Practice Guide

There are certain Core Practices in Agile that are important to understand. If you’re performing some or all of these core practices then you’re likely getting the benefits of Agile whether you call yourself an Agile team or not.

One of the best ways to increase your Agile knowledge is through the Agile Practice Guide from the Project Management Institute and Agile Alliance.

Check out the video and article below!

Release and Iteration Planning

When we’re release and iteration planning for Agile life cycles, two kinds of planning occur. In release planning, our business representatives establish and prioritize user stories for the release. Our business representative is that Product Owner role, but could also be another person who represents the business or the customer themselves who you’re doing the work for.

Part of their role involves gathering the requirements, and they’re defined as the Product Owner role in the Whole Team Approach. We gather that whole team together remember for an Agile project. They will establish and prioritize user stories for a release, collaborate with the team, and they’ll refine larger user stories (big pieces of work) into a collection of smaller stories, features or items. So different people can work on different cards and all up it’ll be a part of this larger release.

This then results in backlog preparation.

The backlog is the ordered list of all of the work, presented in a story form for the team. That story is usually “As a [role]”, “I want [feature]”, “So I can do [requirement]”.

Continue reading Release and Iteration Planning – The Agile Practice Guide →