Category Archives: Agile

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 →

Retrospectives – The Agile Practice Guide

Agile, , , , , ,

– Back to the Agile Practice Guide (all) –

The Core Agile Practices

There are certain core Agile practices, that when you practice them you will gain the benefit of Agile whether you call yourself an Agile team or not. In fact, many different organisations might be using many different Agile Framework names, but not practicing many or all of these practices behind the scenes.

Knowing the practices themselves will also help you get a deeper understanding of Agile as an approach. The Agile Practice Guide by the Project Management Institute and Agile Alliance has all of this information, and this one in particular is retrospectives.

Check out the video and article below!

Agile Retrospectives

In Agile development a retrospective is a meeting often held at the end of an iteration of around two weeks. As we’ve seen, iterations can be between two and four weeks, where we’re usually releasing an increment that a customer can see, feel and touch. We’re getting that early feedback on whether they’re happy with the product and happy with the requirements of that product.

At the end of that iteration, now we have a short meeting to discuss what was successful, what could be improved, and how to incorporate those improvements and retain those successes that we’ve had in future iterations. That means as we’re going along we’re improving and getting better. So we ask ourselves:

  • What worked well?
  • What didn’t work well?
  • What have I learned?
  • What still puzzles me?

By asking these questions and putting the feedback that we’re gathering back into our process, we are continually improving.

Continue reading Retrospectives – The Agile Practice Guide →