Tag Archives: agile project management

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.

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 →

Early and Frequent Feedback – The Agile Practice Guide

Agile, , , , ,

– Back to the Agile Practice Guide (all) –

Core Agile Practices

There are certain core Agile practices that, when you do them with your team, they increase your team’s engagement and results. You also don’t need to call yourself “Agile” – if you are doing some or all of these Agile core practices then you could class yourself as an Agile team, and you will no doubt already know the benefits they bring.

This particular core practice is “Early and Frequent Feedback”.

Check out the video and article now!

Early and Frequent Feedback

When you’re working on an Agile project or delivering in an Agile way, your projects will usually have short iterations.  These short iterations are usually time-boxed pieces of work from two to four weeks, where you deliver something or showcase something for feedback. By releasing something in short cycles what we’re actually doing is enabling a project team to receive early and continuous feedback on the product’s quality throughout the development life cycle.

Continue reading Early and Frequent Feedback – The Agile Practice Guide →

The Agile Whole Team Approach | Agile Practice Guide

Agile, ,

– Back to the Agile Practice Guide (all) –

Agile Core Practices

Looking at the core Agile practices from the Agile Practice Guide is a great way to see if a team is really Agile, even when they may call themselves something different.  This is direct from the Project Management Institute and Agile Alliance.

Watch the video below to find out now!

The Whole Team Approach

The Whole Team Approach means involving everyone with the knowledge and the skills necessary to ensure project success. What that means is instead of having to gather different people from all around the organization or another area to actually work on your project in little bits and pieces, we’re including them all in the one, whole team. They’re one hundred percent dedicated to the project and can really deliver much more quickly.

The team should be relatively small, as successful teams have been observed with as few as three people and as many as nine people. The reason for that is when you’ve got only three people, the communication channels are much smaller and much easier. You can’t have a lot of side conversations or a lot of extra conversations on scope, and overall the communication is much simpler. When you’ve got twenty people for example or many different people you could have conversations in many different channels, and from many different people as well.  All of a sudden the communication becomes a lot more complex.

Continue reading The Agile Whole Team Approach | Agile Practice Guide →

The Agile 12 Clarifying Principles

Agile, , ,

– Back to the Agile Practice Guide (all) –

The Agile 12 Clarifying Principles

These are the principles that dig deeper into the Agile Manifesto and mindset. Check out the video and article below to see if your team truly follows the Agile concepts in the way that is right for you.

We’ve already had a look at the Agile manifesto and mindset where we value the items on the left:

  • Individuals and interactions
  • Working software
  • Customer collaboration
  • Responding to change

…more than the items on the right, which are your typical linear methods or waterfall approach. Now we’re delving into it in a little bit more detail using the Agile 12 clarifying principles. When we’re delivering in an Agile way of course you know we’re using iterations where we’ve got time boxed work of between two to four weeks and we’re often delivering an increment to the customer, which is a “feature” that they can see, feel and touch, just to make sure that everything is on track, that they understand what’s being delivered and that the requirements are fit for purpose. So number one is:

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

And that’s done through that iterative and incremental approach that we will be looking at in this series. You’ve got iterations of between two to four weeks where we’re putting all that feedback back into the product and we’re getting that feedback from the customer. And increments, where we’re delivering a feature so that the customer can just tell for themselves whether the requirements are fit for purpose.

Continue reading The Agile 12 Clarifying Principles →

The Agile Manifesto and Mindset

Agile, ,

– Back to the Agile Practice Guide (all) –

The Agile Manifesto and Mindset

Do you know where Agile all began?  The manifesto behind one of the fastest growing project management and product development methodologies of the new millennium?

Check out the video and article below as we go through the Agile manifesto and mindset.

Where it all began.

In 2001 a group of individuals representing the most widely used lightweight software development methodologies agreed on a common set of values and principles which later became known as the Agile Manifesto.

The Agile Manifesto contains four statements of values, and this is where it all began. You’ll see that there’s many methodologies or many Agile practices that come out of Agile that you’ll learn about soon, but they all stem from these core principles and these core values that came about in 2001. The four Agile Values are:

We value individuals and interactions over processes and tools.

So while processes and tools are important we value individuals and interactions more than processes and tools, and you’ll see that in the practices of agile where we have daily stand-ups and we’re really interacting to remove blockers on a daily basis rather than letting them simmer. So this is where we’re interacting and we’ve got the whole team approach where everyone who’s needed to be in a project is actually within that team – you don’t have to go externally or find them in other departments, they’re all within the one team. You can talk to them quite quickly and immediately. Next we prefer:

Continue reading The Agile Manifesto and Mindset →

What is Servant Leadership in Agile Project Management?

Agile, , ,

– Back to the Agile Practice Guide (all) –

Do you know what it means to be a Servant Leader in Agile Project Management? Whether you’re a Scrum Master, Project Manager, facilitator or coordinator, understanding Servant Leadership will help you.

Check out the video below, now!

Servant Leadership – Agile practices

From the Agile Practice Guide, by the Project Management Institute and Agile Alliance. Agile approaches emphasise servant leadership as a way to empower their teams. Servant leadership is the practice of leading through service to the team – so in other words you’re the leader, you’re the boss, but your customers are actually your team members.  As a servant leader you’re here to serve them as well and help them get what they need so that they can do the best job that they possibly can.

That means understanding and addressing the needs and development of the team members to enable that highest possible performance.  Servant leaders approach project work in this order – first of all we start with the “why”.  That’s a classic book from Simon Sinek, and many people have written about it.  We don’t start with what we’re doing we actually start why we’re doing it.

Continue reading What is Servant Leadership in Agile Project Management? →

When to Use Agile, Waterfall, Iterative or Incremental Project Life Cycles

Agile, , , , , , , , , ,

– Back to the Agile Practice Guide (all) –

Project Development Lifecycles

Project Life Cycle Deep Dive!

Do you know when to use Agile, and when to use Waterfall?  Do you know the difference and benefit of using iterations versus increments, or both?  From the Agile Practice Guide from the Project Management Institute (PMI) and Agile Alliance, we look at the four types of Project Lifecycles and the best times to use them.

Check out the video below now!

We’re looking at the characteristics of project life cycles from the Agile Practice Guide from the Project Management Institute and Agile Alliance.

Previously we’ve looked at the different types of life cycles.  We’ve got the predictive life cycle which is your traditional waterfall approach – very step-by-step.

We’ve got an iterative approach where we’re iterating, and we’re not necessarily releasing something but we’re getting feedback on a regular basis, usually every two to four weeks.

Then we’ve got the incremental life cycle and that is where we’re actually delivering an increment to something usable that a customer can can use see feel and touch and getting that feedback as well using that approach.

Lastly the Agile approach which is both incremental and iterative so we’ve combined those two things or we’re iterating towards success building that feedback back into the product but also releasing that product on a regular basis to refine that work and to deliver frequently.

So let’s delve into the characteristics of these life cycles a little more deeply.

Continue reading When to Use Agile, Waterfall, Iterative or Incremental Project Life Cycles →