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.

Leadership Quote – Clarity and Simplicity from General George Casey

Quotes,

– See all the Leadership Quotes here –

“Clarity and simplicity are the antidotes to complexity and uncertainty.” – General George Casey

Do you know this quote by General George Casey?  General Casey served in the U.S. army his entire working life, most notably as the Chief of Staff of the United States Army from 2007 to 2011.  He had to deal with all kinds of complexity and uncertainty – complexity that would cost thousands of lives if he made a wrong decision.

Dealing with it over so many years it goes without saying that he knows a thing or two about the antidote to complexity and uncertainty, and that is Clarity and Simplicity.

Leadership Quote Clarity and Simplicity

Clarity and Simplicity

Just as his quote is clear, concise and simple, so are the actions he recommends.  But what does it mean to bring Clarity to your team?

Clarity means your team knows their objective.  They know the goal, and they know where they are heading.  Often a good leader will set these objectives collaboratively with their team, to help them to buy in to what needs to be done.  Clarity means making a plan, and knowing the steps to execute that plan.  When you have clarity on what needs to be done and how you are going to do it, there’s quite simply a much higher chance it will get done.

I have seen this personally happen time and time again across many different industries – from McDonald’s and the fast food industry to financial services, banking, trading and insurance, automotive and more.  The teams that are clear on their objectives and their plan, are the teams that win.

And what does it mean to bring simplicity to your team?

Simplicity means being able to reduce the steps to getting the outcome you want.  It means finding the lowest common denominator, the clearest path, the smoothest way forward.  Albert Einstein is credited with saying “If you can’t explain it simply, you don’t understand it well enough.”  That means only someone who truly understands something can articulate it in simple terms – others will go on and on trying to convince everyone, including themselves.

So bring simplicity and clarity to your team – you will see their employee engagement soar and your productivity improve.

– David McLachlan

Get the Leadership Card Deck or the Lean CX Score Book:

Leadership CardsView All The Leadership Cards (48)

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

 

Lean CX ScoreGet "The Lean CX Score" now, and start creating disruptors in your industry that completely annihilate your competition.

Oh and good news!  You'll be improving the speed, morale and engagement of your teams at the same time.  Get the Lean CX Score now.

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.

Leadership Quote – Lao Tzu on Servant Leadership

Quotes, , ,

– See all the Leadership Quotes here –

“A leader is best when people barely know he exists…when his work is done, his aim fulfilled, they will all say: We did it ourselves.” – Lao-Tzu

This is an old, yet timeless leadership quote from the founder of Taoism, Lao Tzu, who lived in China around 600 years BC.  And thankfully we can add “he or she“, and “his or her aim” today, as we’ve made strides towards equality over the last 1600 years that Lao Tzu wasn’t privy to, and we’re blessed with many wonderful women leaders, both high profile and local.

Do you know what this quote means?  Lao Tzu is talking about “servant leadership”, 1600 years before it became a popular leadership method and framework, which is amazing in itself.

Leadership quote lao tsu We Did It Ourselves

Empowering Your People So They Can Do It Themselves

There are as many different leadership styles as there are personality styles, although you may know the most common ones: from the Autocratic, where the manager is primarily focused on getting the tasks done with little regard to a team’s feelings, to directing, democratic, laissez-faire or “hands-off”, charismatic and transactional.

But there is one leadership style which has grown in popularity, especially with the rise of Agile and Lean methodologies in and around software development, and that is the Servant Leader.

Continue reading Leadership Quote – Lao Tzu on Servant Leadership →

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 →

Leadership Quote – Set a Goal to be Happy

Quotes

– See all the Leadership Quotes here –

“If you want to be happy, set a goal that commands your thoughts, liberates your energy, and inspires your hopes.” – Andrew Carnegie 

This is a great quote from Andrew Carnegie – who was once the richest man in the world. He came from humble beginnings and built a steel empire in the early 1900s, so you might say he knows a thing or two about setting the right goals.

Leadership Quotes set a goal to be happy

Why The Right Goal Matters

Everybody tells you about goal-setting. We all know we need to write down where we want to be, or else the winds of circumstance will take us down a remote and different path.

But taking it to the next level, we need to set a goal that really gives us energy.  When you write down what you want to do – start a business doing this or that, write a book, speak on stage, become a leader – do you feel happy?  Do you smile slightly?  Or does your stomach sink a little bit.  If it sinks, it’s probably not something you are going to be able to work towards for 15 hours a day to set yourself apart from the pack.

Take the time to write down different things and notice your body’s reaction. You might call it your natural intuition, or trusting your gut. Simply by noticing it, you can choose a goal that inspires your hopes, just the same way that Andrew Carnegie was talking about.

– David McLachlan

Get the Leadership Card Deck or the Lean CX Score Book:

Leadership CardsView All The Leadership Cards (48)

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

 

Lean CX ScoreGet "The Lean CX Score" now, and start creating disruptors in your industry that completely annihilate your competition.

Oh and good news!  You'll be improving the speed, morale and engagement of your teams at the same time.  Get the Lean CX Score now.

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.