Tag Archives: OpenAgile

Cultivating a Learning Culture

I’ve recently joined Berteig Consulting Inc., and we are wrapping up our first cycle as a new team. The last two weeks has been an extraordinarily rich experience for me in a multitude of ways.

The time I’ve spent reviewing various online and published Agile reference materials, thinking deeply about the concepts in the Agile Manifesto and Principles, studying some in-house materials and portions of different books about agile coaching and retrospectives has been really useful to my deepening in the concepts surrounding the framework of Agile. Even more helpful though has been the fact that I have had the opportunity to complement this reading and studying with action and engagement with our clients, and that our team has been so open to the reflections I’ve shared and has shared their own. Previous experiences have taught me that familiarity with resources and guidance, without practical application, can be limiting and create an over-intellectualization of concepts that, when divorced from action, can create an artificial version of reality, and that makes me even more appreciative for the time I’ve been able to spend interacting with clients and thinking about what I’ve been reading about and how this would be applicable to their teams.

Our team regularly articulates and works to apply concepts we think are foundational to growth and transformation, such as truthfulness, consultation, and agility in thinking and action at the individual and group level. I’ve found that our ongoing communication in our team room and reflection throughout the day has been instrumental in creating a space that is open and forward moving for us.

I’ve also realized a lot of factors have contributed to the culture of learning we are continually developing in our team, including our openness and honesty during progress meetings, our efforts to use consultation as a guide and instrument when we’re trying to make decisions, the actions we take to complete a task, and our readiness to respond to change. I think we’re also all really aware in our team how important our approach to the process of learning is. I’ve found this manifested in different team members in different ways: experienced ones practice coupling expertise with humility, others display incredible levels of patience and servitude to the team, still others animate the group with high levels of joy and kindness.

We also each seem to have a very conscious appreciation for the new culture we are trying to create within our team, which will help us in accompanying other teams to develop as well. Personally, I am continually striving to transform my actions to reflect what I learn through each experience each day and feel that the individuals on our team are doing the same. We increase our understanding of how to transform our own actions and those of the team as a unit as we apply what we are learning simultaneously to areas and interactions beyond ourselves. From what I’ve seen so far, transformation is a key concept with every team we are engaged with, and I think that we can contribute to that process a lot more if we are also always trying as a team to do the same.

The spirit of collaboration I have experienced within our team and with our clients has been really uplifting to me and for that I thank each of you, my collaborators, for your contributions and all that we have been able to do and learn together.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Reader Survey: Important Topics for an “Agile for Managers” Workshop

Hi Everyone,

We have started putting together a list of topics / learning objectives for a new course: “Agile for Managers”. I am interested in getting suggestions from readers on topics to include. What are the challenges you have had with managing agile teams? If you are on an agile team, what are some of the challenges you have had with management? What are the burning questions you have as a manager about deciding to use agile methods? What have been some of the critical success factors in adopting agile methods? What about pitfalls?

I will summarize feedback in a future article as well as post a proposed agenda for such a workshop. In order to “give back”, I will also make the initial draft of the course materials available under a Creative Commons license so that others can use the materials.

I look forward to hearing your thoughts!


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

AgilePM + Scrum(CSM) + OpenAgile + Kanban training in Markham Sept. 7 & 8

We have an upcoming three-day agile training seminar in Markham September 7 & 8, 2011.

In this unique seminar, we will be offering a practical view of three important Agile methods: OpenAgile – used for general agile project management and agile teamwork including projects and organizations doing any kind of work. Scrum – used for software new product development and IT project management. Kanban – used for teams doing operational work.

This seminar contributes towards three certification programs: the Scrum Alliance’s Certified ScrumMaster program, the OpenAgile Team Member level and the IPMA/PMAC Agile Project Management certification.

To register: http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars

Proudly delivered by Berteig Consulting, a Canadian organization since 2004.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

AgilePM+Scrum(CSM)+OpenAgile+Kanban training in Toronto, August 22-24

We have an upcoming three-day agile training seminar in Toronto, August 22-24, 2011.

In this unique seminar, we will be offering a practical view of three important Agile methods: OpenAgile – used for general agile project management and agile teamwork including projects and organizations doing any kind of work. Scrum – used for software new product development and IT project management. Kanban – used for teams doing operational work.

This seminar contributes towards three certification programs: the Scrum Alliance’s Certified ScrumMaster program, the OpenAgile Team Member level and the IPMA/PMAC Agile Project Management certification.

To register: http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars

Proudly delivered by Berteig Consulting, a Canadian organization since 2004.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

AgilePM+Scrum(CSM)+OpenAgile+Kanban training in London, Sept. 7-9

This 3-day training covers 3 Agile methods: ScrumMaster (the most popular Agile method), OpenAgile (the most widely applicable Agile method), and Kanban (a method that can be used together with other Agile methods).

To register: http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Remember that Agile is about Quality and Business Value

Recently, I had an interesting discussion with a companion about Agile Processes and the need for corporations, communities or groups to change their approach to planning and doing work. We were discussing using OpenAgile as a Framework.

The person I was talking to told me that their group (Artists) were already used to and embraced the idea of shared responsibility, self-organization, mutual respect and open discussion to get things done. OpenAgile (as well as Scrum) require open communication and truthfulness to be effective tools for self-organization.

My friend then told me how it made sense in the Art Community but it would be hard for Financially minded people to believe in what Agile was about and that it would be even harder for financially oriented educators (ie: Universities and Colleges) to change their minds about teaching Agile processes as a primary part of the education system.

Then it struck me.

For many people, they hear FIRST about the need to share work, how the organization changes, how people are treated better and all the usual comments.

I realized I need to change my approach with these types of people to first discuss how agile processes work to benefit Business Value and Quality. My 15 second elevator speech should start with these ideas and not the other way around.

I don’t know of any business leader, financial manager, non-profit CEO or educator that would think it to be a bad idea if I said to them “Listen, I would like to show you a way to do the most valuable things first, with exceptional quality while at the same time consistently getting better at it. Oh, and as a by-product, you will also have more engaged, long-term staff. What do you say ?”.

We must admit that OpenAgile (or any other Agile process) is not a silver bullet to be used everywhere for all groups. I have however found that after teaching about iterative work and the IDEA of Business Value and Return on Investment, even a “non-agile” team can still benefit from some of the procedures or “routines” of a fixed cycle of learning and it’s heartbeat.

All of the new ways of doing things including culture shift, team based work, etc. would be unfortunate for a business without first remembering that the purpose is to provide Quality and at the same time provide the items that have the most VALUE to the organization.

Quality is an inherited part of the process of going Agile. As more discussion happens and all people in the team have input into the process, inevitably, you should end up with a better result. The customer has more direct input into the final product as it is being created, therefore helping to achieve a result that everyone is happy with.

The real goal to business is this Quality, and the way to get there is all these things that Agile asks us to do, through a continual process of learning.

Business Value. This means different things to many people. Where you are using OpenAgile, Scrum, XP, Pomodoro, remember, the goal of all of these is to work on the tasks that will provide the company or organization to most Business Benefit First.

When coupled with the idea of Return on Investment, the reasons are just far too compelling to an organization to ignore. After all, no organization of any type can afford to exert effort with no return at all in the form of artifacts of some sort. Every organization is there to create some kind of result (value) in its’ chosen field.

Most organizations have many different opinions and reasons for considering one item more valuable than another. You will likely find that most people think ALL of their backlogged items are of equal value to a project or company.

The idea of doing work based on Return on Investment takes some of the emotion out of this process to allow work that is clearly more beneficial to the group to take precedence.

When a task is determined to be of lower value (not because of just value, but work for value) doesn’t make it into this cycle, it MAY well be classified as a higher Value for the next cycle, and therefore, it’s Return of Value / Work may be higher and bring it up the work scale through this process.

There are several ways to accomplish this. One of the easiest is by breaking the item to be done into smaller pieces. It’s Value will remain the same, but the work (effort) required to complete that smaller piece will be less. Therefore, the new smaller task will have a higher Return on Investment and be done sooner.

The idea is that true business value is what is provided first with many competing priorities. Most of us don’t have the ability to just add two or three more teams when more work comes along, so there needs to be some logical process to deal with this.

For my friend in the Arts who is wondering about the Financial Elite having a hard time doing a mental shift towards Agile processes instead of Waterfall processes, consider the conversation about Return on Investment and Quality of the Final product as your starting point. THEN let them know, “Oh ya. you’ll also end up with less turnover and happier employees”. :->

Mike Caspar

References :

OpenAgile – http://www.openagile.com
Scrum – http://www.scrumalliance.org
Pomodoro – http://www.pomodorotechnique.com
XP – http://www.extremeprogramming.org


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Why is hardware being forgotten by development companies?

This week I met someone while on a personal trip who is in the software business.  His company writes software for a very specialized vertical and from everything he said to me, they are an innovative company and do all the right things including empowering their teams to self-organize, regular training for the staff and generally a great working atmosphere.

The company has still been struggling with getting their product to be “deeper” (his word) for their client base.

I was again reminded of a post of mine from a while ago encouraging or providing cross-training or at least some knowledge to bridge the barriers between the software group and the hardware group (link at the bottom of this post).  In my environment, I’ve been fortunate to have a network admin sitting with our team.  It has prevented many potential problems.

Having been involved in the infrastructure part of IT as well as development, I knew of at least a few products almost immediately that could make his product more compelling to his customers.

To my surprise, I found out his company was only looking at software improvements to their application.  He told me how they are continually developing new features but are not considering running on any new platforms.

I mentioned a few technology (hardware) improvements he could consider and I know that by the time he gets home this weekend, he will have taken a look and passed the information on to his team.  These improvements could immediately add significant customer retention and usability to his product.

From our discussion, it was also evident that his team would enjoy the challenge of some new platforms to keep encouraged about the future. I’m sure that by the time he reads this, he’ll have some of these technologies in hand :->

As Agile practitioners, it seems, we are so focused on improving our software development cycle, our specific development tasks, our daily or hourly builds, our programming skills, and how we create story points, sometimes we seem to lose track of the big picture… What is the customer going to use it on?  This should be fundamental to every developer’s thought processes.

Think to yourself,  “HEY, should we be seeing if our software could run on some of the new technologies out there such as Microsoft Surface, some of the new Wireless Devices, or even benefit somehow from new 3D technologies coming out”?

I like to think that developers who are empowered with information about hardware can think of all kinds of ways to use it.

If you’re on an Agile Team or managing one, ask to learn something about the hardware in your environments.  Consider some “slack” in your Sprint or some work breaks in your Cycle to allow team members to learn something about new Infrastructure or Hardware products.

Think for a moment if your company is writing software for the Web, the power of a deep understanding of how a load balancer actually works, or my personal favorite, the .NET Cache.

Let it be the teams’ choice of which products though. That will give the best motivation and most likely will be the most enjoyment for everyone.

It will broaden your horizons and perhaps give your team ideas you never knew could even be possible.

If we always just wait for a Marketing Person or Product Owner to come up with interesting ideas, where’s the fun in that?

References :

My previous post – Infrastructure Knowledge for Developers
3D example – Sony 360Degree viewer prototype
Microsoft Surface – Microsoft Surface Web Site
Slack – A good article about slack in XP by James Shore
Sprint – Scrum Alliance
Cycle – Open Agile


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Upcoming Scrum/Kanban/OpenAgile Seminar in Waterloo – May 4-6

Just a quick note to let people know that there are spots available in the course we are delivering next week in Waterloo. Details can be found here.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Stress-Free Priority Meetings using Planning Poker Cards

For many of you, there will be instances where Scrum or Agile is something a company is trying but does not really buy into or understand yet. I would like to start by saying.  There is hope!

The  following story is about implementing Planning Poker in Priority Meetings at the senior management level using the OpenAgile’s Open Learning System. Perhaps it could help you introduce Agile to different parts of your organization.

For those types of companies, Agile Development processes can be introduced and progress made with very little effort on your part.  You won’t get the full benefit, but at least people will get to know Agile as a great way of making real progress in an organization.

Consider the following situation…. You work for a company that has “heard” of Agile and is allowing you to implement whatever you can in regards to Agile for the Development Team “as long as it doesn’t affect other parts of the company too much”.

If you’re like me, you’ve likely heard this more than a few times.

I recently had an opportunity to find a new way to introduce Agile Processes to senior managers who are not really familiar with the processes and also are not willing to put the time in to learn them.

I’d like to pass on an idea about how you could possibly make some small headway in regards to Planning.

Imagine you are working at a company where there are several owners or stakeholders responsible for the future “work backlog” of features for your environment.

Generally, when planning sessions take place, it involves an aggressive battle over who will get what feature first, what is more important (systems, back-end, front end, graphics, this enhancement, that enhancement).. You all know the drill.

I had many such meetings with the stakeholders of a company where I had the opportunity to introduce Planning Poker Cards to these meetings with great success.

Here’s how….

About once every 1 or 2 months, a “priorities meeting” was scheduled for a Wednesday afternoon.  After successfully implementing Agile process for the development team, it was time to help the rest of the company out.

I prepared by doing a few things;

– Prepared pictures of existing Scrum Rooms to show how developers and planning boards would eventually look (thanks to Mishkin Berteig of Berteig Consulting for providing additional examples).

Of course, I made sure of standard things such as making sure the PowerPoint will work on the equipment in the meeting room. When it came time for the presentation, I knew it would work. It’s hard to show how productive your processes are if you can’t get yourself properly organized.

-I made sure I had a deck of Planning Poker Cards available.

-I explained to the Stakeholders that I would like to do something to “take the emotion out” of the planning process and make sure everyone’s opinion is heard and valued.  I explained how this process was intended to make the planning a very business-like process, and a way for us to quickly get through what was generally a long, several meeting process in one easy step.

-I asked them to trust me (which remarkably goes a long way), and said, “I would like to show you this to try and move the meeting along, take out the emotion and have us end up with  the best ROI (Return on Investment) in future.  I asked if they would agree to give it a try.

I made sure to warn them about the process of Forming, Storming, Norming, and Performing and mentioned that if they had interest they could look it up on Wikipedia.

At first, there was little interest in learning or seeing the processes because of course anything about “Agile Stuff…has nothing to do with Senior Management”, so it was all a matter of “Let’s get down to it” as to not waste time.

I took about 20 items from the queue and converted them to Index Cards and put them on the table.

I asked them to find the least valuable item to get done (there are literally hundreds of backlogged items). This alone seemed like it might take a considerable amount of time, so I decided to take a slightly different approach.

I waited for an index card that I knew I could get agreement on as being of fairly low value and had my starting point.  There may have been lower items, but this could safely be agreed upon by everyone as a low priority or low value item. This process works well as it’s usually easier for people to agree on what’s not important or valuable. I’m not sure why… But hey, it works!

It took only a few cards and although the process was not in “strict adherence” to the no negotiation and no showing your cards rules, in this case it was VERY effective.

The owners of the company prioritized BY VALUE several hundred feature requests in just over 2 hours. I think it’s astounding that by just letting them make up their own system with what I introduced to them, they also were able to self-organize, agree on a different approach, and be successful with their own way of doing things. All I needed to do was introduce them to the tools.

A few times during the cycle, I needed to re-affirm the process was about VALUE only and not about how long these would take. This seemed to be a large stumbling block at first, but eventually it was accepted. I explained that the development team would be the estimated (Investment) part later.  We would divide their value (return) / by the developers estimates (investment) and the system would work itself out by providing a general Return on Investment Calculation.

They asked me about what would happen with all the cards… And, now the opportunity to show pictures of Scrum Rooms or Agile Rooms presented itself.

The managers were very happy with idea that they could “adjust priorities” many releases in advance.  This for them, was a big bonus.  I explained that once we have big boards with all the User Stories on them, it would benefit everyone.

Features and Defects for a Release
Features and Defects for an Agile Release

– Everyone in the company could go to the board and see what features were going to be coming soon.  This turned out to be extremely motivating for the Sales People.  The idea of knowing what at least was being Planned was exciting to them.  Of course, I explained to them and the sales manager that there were no guarantees of what would get done if at all, but at least they would know if any of their specific requests were even in the pipeline at all.

– The senior management have always been wondering how the Development Team was doing.  This was the ideal solution.  A big giant board that everyone can understand at a glance easily solves this. Such a simple technique and yet so powerful!

– An idea how the current release is going.  As Scrum or OpenAgile practitioners, we all know the value of this type of information is amazing.  To know how far in the cycle you are based on simply looking at the Board is so simple.

– In the past, the development team generally knew what was coming up only 1 or 2 releases before it was time to do the work.  Knowing what’s coming down the pipe avoids potential code conflicts, systems conflicts, marketing conflicts, and generally keeps everyone motivated and excited about the future.

– An un-expected side effect which I was not expecting was that there was a developer who was worried about future work.  Seeing hundreds of cards in the queue of work solved that problem.  As we all know, lists  of future work can usually be never ending :->

Teams can then start estimating the Work portion using the same system.  What you end up with is ROI (value over investment) for your queued up work.  The company may not live with it, but it gives a simple starting place for everyone to discuss openly.

Another real benefit is that the emotional roller coaster of settings priorities is much less a factor with this type of process. Everyone has agreed as a team to the Value and everyone has agreed as a team to the Estimates, so there’s really nothing other than pure politics to stop the plan from working now.

I was pleased that at the end of the first attempt at doing this, there was an overwhelmingly positive response.

There were a few surprises.  For instance, one of the managers wanted to be in the Estimating meeting with the developers to Ensure we “get the right answers”.  However, I needed to stand firm.  Again, I asked them to trust me and simply said “No, it won’t work that way, sorry… I DO promise, though that  if there is something we don’t understand, we’ll consult you.”… The Stakeholder was happy with that.

In reality, all that manager was worried about was that we might consider one of their tasks less important or overestimate the intention and therefore overestimate the time it would take to complete, and therefore, lower the ROI on it.  That owner wanted to ensure that a very specific high priority project got put into the queue.

It is after all their company.  We all need to remember that owners need to have some rights as well <grin>.

In my case, I know that what might happen is that one or some of the items may end up overstepping the process due to factors outside the teams’ control.

This is a reality of working in a smaller development environment… actually… in reality, many environments.

However, I still consider this a major breakthrough for several reasons.

1 – Even if a few items bypassed the process at least the several hundred other features and tasks did not.  Who can complain about that!

2 – The owners were now in the “frame of mind” that tasks can be easily be classified as to value.

At first it was difficult for them to specify value for large features because they believed they might be huge projects and they didn’t want to send the team on a huge development task and risk losing other important features that were already in the queue.

I explained to them to not worry about this as the ROI formula will actually make these projects less of an ROI at THIS time.  As they want to move the bigger cards closer to the upcoming release, we will break them into smaller pieces in the same fashion and eventually those parts of the system would be worked on as the smaller parts would have potentially higher ROI’s.

This of course, made sense to them.  The key here is that huge tasks should be split into smaller tasks as they get moved on the Planning Board, Information Radiator or whatever you want to call it.  As items move closer to the release cycle, their value should naturally be increasing as well.  Then, upcoming features can be re-sequenced and prepared to get injected into the development process using another planning cycle.

All the time, it’s about Value for Work performed….. This is of course what being in business is all about.

Some values are about taking care of long-term customers, some are purely political and some are just about making sure the system doesn’t crash. Value is about the overall impact to the health of the organization.

Planning cards make this a non-emotional event.

I knew the system was working because a funny thing happened. Several days after the first planning cycle, I received notification of new Feature Requests from clients and our support department with some unusual coding on it.

“The ABC type of customers are looking for this feature in the product;  It’s something we really should consider doing soon… We’ve talked about it and think it should be at card level 8 or 13”.

This to me was a great thing to see!

For those of you who don’t know;  Scrum or OpenAgile Planning Poker cards are purposely set up to have a non-uniform number sequence to avoid mathematical calculations and exact figures.  They are about relative value to other each other and not fixed numbers.

The key is to keep it simple and remind everyone using the cards that this is not intended to be a perfect estimation.  This is a relative estimation of value or work.

The fact that the stakeholders had started using this terminology showed that they not only understand that process but truly see its’ value.

One complaint from the past had always been that everything has been either High Priority, Medium Priority or Low Priority.  Planning Poker Cards have helped them to take the emotion out of the Priority process and ultimately give them Many Levels of Value Priority in a simple way.

Perhaps planning poker might help in your environment to help set priorities, not just for development but for any set of complicated project.

Many of us think of Planning Poker as a developer only thing, but as you can see from this story it can be used as an effective tool for any process.  Give it a try and you might just be surprised at how stress-free of a process it can really be for your priority meetings.

The read about the specifics of Agile Planning Poker, try Wikipedia.

To find out more about OpenAgile and its’ flexibilities regarding release, or cycle planning, go to http://www.openagile.com.

Mike Caspar, CSM, Open Agile Certificate Holder
http://mike-caspar.blogspot.com


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Assessing an Organization for an Agile Transformation Plan

Myself, Paul Heidema and a few other people we work with have now participated in several assessments of organizations who are either looking at adopting agile methods or improving existing use of agile methods. We have developed several tools for running these assessments. The following things are critical to the assessment process and the results we get:

Culture

The success of an agile transformation is primarily driven by connection that transformation makes with the existing culture of the organization. We know that doing an agile transformation includes cultural changes. The critical piece is understanding the culture so that you can determine what in the culture supports agility and what in the culture is going to hinder agility. A culture that focuses on individual accomplishment and freedom will not support agility well, while a culture that supports doing the best possible thing for customers will support agility. Of course, any given organization will have a mix of cultural aspects that both support and hinder agility. There are a number of methods for examining culture including an excellent corporate culture workshop described in the book “The Corporate Culture Survival Guide” by Edgar Schein.

Value Stream Mapping

A high level value stream map is an excellent tool for identifying both an overall need for improvement by making the current state of affairs visible, as well as pinpointing where big improvements can be made quickly. More often than not, when we do an assessment for an organization, we are finding that the efficiency of their process is at about 20-30%… in other words, 70-80% of all effort is expended on wasteful activities. This level of waste is often surprising for stakeholders. And of course, making that level of waste visible is a large motivator for the kind of continuous improvement that agile methods such as OpenAgile and Scrum make possible.

Agile Practices

Of course, even if an organization is not doing agile officially, there are often existing practices that can be considered part of the overall umbrella of agile. A comprehensive assessment that rates a team’s or an organization’s level of use of agile practices gives a good picture at a very practical level of what things you can build upon. For change to be successful, a significant factor is to tie new practices to existing practices. This is a great way to do this. There are lots of lists available of agile practices. We publish one fairly comprehensive list of agile practices on the Berteig Consulting site (it’s near the bottom of the linked page).

There are of course many other things that are done during an assessment, but these three form an effective foundation for any agile transformation plan.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Toronto and Ottawa Courses have Spots Available

Our agile methods seminar with Certified ScrumMaster, OpenAgile Team Member and Kanban next week in Toronto and our Certified ScrumMaster seminar the following week in Ottawa both have spots available. Just a reminder that these seminars are a great choice if you are thinking about getting training, need PDUs for the PMI, or if your organization is struggling with using agile effectively.

Hope to see you at one of these!


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Calculating a Budget for an Agile Project in Six Easy Steps

A former student of mine called the other day.  He asked a good question: how do you calculate the budget for a project if you are using an agile approach to delivery.  Here is the overview of the six steps to do this.  I will follow the overview with some detailed comments.

  1. Prepare and estimate the project requirements using Planning Poker
  2. Determine the team’s Velocity
  3. Using the team’s burn rate and velocity calculate the budget for the Iterations
  4. Add any capital costs
  5. Using the definition of “done” add pre- and post- Iteration budgets
  6. Apply a drag or fudge or risk factor to the overall estimate

Prepare and estimate the project requirements using Planning Poker

The project requirements have to be listed out in some order and then estimated.  If you are using Scrum as your agile approach, you will be creating a Product Backlog.  Extreme Programming and you will be creating user stories.  OpenAgile and you will be creating Value Drivers.  Kanban and you will have a backlog of work in progress.  Regardless of the agile approach you are using, in a project context you can estimate the work using the Planning Poker game.  Once you have your list, you need to get the team of people who will be working on the list to do the estimation.  Estimation for agile methods cannot be done by someone not on the team – this is considered invalid.  It’s like asking your work buddy to estimate how much time it will take to clean your own house and then telling your kids that they have to do it in that amount of time.  In other words, it’s unfair.  Planning Poker results in scores being assigned to each item of your list.  Those scores are not yet attached to time – they simply represent the relative effort of each of the items.  To connect the scores to time, we move to the next step…

Determine the team’s Velocity

The team needs to select its cycle (sprint, iteration) length.  For software projects, this is usually one or two weeks, and more rarely three or four weeks.  In other industries it may be substantially different.  I have seen cycles as short as 12 hours (24/7 mining environment) and as long as 3 months (volunteer community organization).  Once the duration of the cycle is determined, the team can use a simple method to estimate how much work they will accomplish in a cycle.  Looking at the list of work to be done, the team starts at the top item and gradually working their way down, decide what can fit (cumulatively) into their very first cycle.  Verbally, the conversation will go something like this:

“Can we all agree that we can fit the first item into our first cycle?”

– everyone responds “Yes”

“Let’s look at the second item.  Can we do the first item AND the second item in our first cycle?”

– a little discussion about what it might take to do the second item, and then everyone responds “Yes”

“Okay.  What about adding the third item?”

– more discussion, some initial concern, and finally everyone agrees that it too can fit

“How about adding the fourth item?”

– much more concern, with one individually clearly stating “I don’t think we can add it.”

“Okay.  Let’s stop with just the first three.”

Those items chosen in this way represent a certain number of points (you add up the scores from the Planning Poker game).  The number of points that the team thinks it can do in a cycle is referred to as its “Planning Velocity” or just “Velocity”.  With the velocity, we can then do one of the most important calculations in doing a budget…

Using the team’s burn rate and velocity calculate the budget for the Iterations

The team’s velocity is a proxy for how much work the team will get done in a cycle.  However, in order to understand a budget for the overall project, we need to take that estimate of the team’s output and divide it into the total amount of work.  Our list has scores on all the items.  Sum up the scores, then divide by the velocity to give you the number of cycles of work the team will need to complete the list.  For example, if after doing Planning Poker, the sum total of all the scores on all the items is 1000, and the team’s velocity is 50, then 1000 ÷ 50 = 20… This is the time budget for the team’s work to deliver these items.    To do dollar budgeting, you also need to know the team’s burn rate: how much does it cost to run the team for a cycle.  This is usually calculated based on the fully-loaded cost of a full-time-employee and you can often get this number from someone in finance or from a manager (sometimes you can figure it out from publicly available financial data).  In general, for knowledge workers, the fully-loaded cost of a full time employee is in the range of $100000/yr to $150000/yr.  Convert that to a per-cycle, per-person cost (e.g. $120000/yr ÷ 52 weeks/year x 2 weeks/cycle = $4615/person/cycle) and then multiply by the number of people on the team (e.g. $4615 x 7 people = $32305/cycle).  Finally, multiply the per-cycle cost by the number of cycles (e.g. $32305 x 20 cycles = $646100).

This is the budget for the part of the project done in the cycles by the agile team.   But of course, there are also other costs to be accounted.

Add any capital costs

Not many projects are solely labor costs.  Equipment purchases, supplies, tools, or larger items such as infrastructure, land or vehicles may all be required for your project.  Most agile methods do not provide specific guidance on how to account for these items since agile methods stem from software development where these costs tend to be minimal relative to labor costs.  However, as a Project Manager making a budget estimate, you need to check with the team (after the Planning Poker game) to determine if they know of any large purchases required for the completion of the project.  Be clear to them what you mean by “large” – in an agile environment, this is anything that has a cost similar to or more than the labor cost of a cycle (remember: agile projects should last at least several cycles so this is a relatively small percentage of the labor costs).  In the previous example calculation, the cost per cycle was $32305 so  you might ask them about any purchases that will be $30k or larger.  Add these to the project budget.

Using the definition of “done” add pre- and post- Iteration budgets

Every agile team is supposed to be “cross-functional” but in reality, there are limits to this.  For example, in most software project environments, teams do not include full-time lawyers.  This limited cross-functionality determines what the team is capable of delivering in each cycle – anything outside the team’s expertise is usually done as either pre-work or after the iterations (cycles) are finished.  Sometimes, this work can be done concurrently with the team.  In order to understand this work, it is often valuable to draw an organization-wide value stream map for project delivery.  This map will show you the proportion of time spent for each type of work in the project.  Subtract out all the work that will be done inside the agile team (their definition of “done”) and you are left with a proportion of work that must be done outside the agile team.  Based on the proportions found in the value stream map, add an appropriate amount of budget based on the project’s cycle labor costs.

Apply a drag or fudge or risk factor to the overall estimate

And of course, to come up with a final estimate, add some amount based on risk or uncertainty (never subtract!)  Generally speaking, before this step, your project budget is going to be +/- 20%-50% depending on how much you have used this approach in the past.  If you are familiar with it and have used it on a few projects, your team will be much better at understanding their initial velocity which is the foundation for much of the remaining budget estimates.  On the other hand, if you are using this method for the first time, there is a high degree of anxiety and uncertainty around the estimation process.  Please feel free to add a buffer that you feel is appropriate.  But again, never, ever, ever remove time or money from the budget at this last step.

Please let me know if you have any comments on how you have done this – tips, tricks or techniques are always welcome in the comments.

Thanks, Mishkin.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Helpful outline of the OpenAgile Primer

David Parker, the Executive Director of the OpenAgile Institute, published a helpful outline of the OpenAgile Primer on his ‘Changemaker in the Making’ blog. Take a look at the Conceptual Outline of the OpenAgile Primer and let it inspire your own thoughtful study.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Agility, the Age of Interactions, and the Military

The United States Department of Defense Command and Control Research Program has published a short (10 pages) paper on the concept of Agility (by David S. Alberts) and the need for Agility for Complex Endeavors.  Lots of fabulous thinking has gone into this paper which is loaded with useful definitions, useful concepts and advice about where we need to go with research.  I STRONGLY recommend taking twenty minutes and reading it right now.

Now that you have read it… no? … go read it!  You don’t have an excuse – you’re reading my blog aren’t you?!

Okay, really.  Here a couple of highlights:

The Age of Interactions

We are no longer in the Information Age.  I _love_ this concept.  It gels well with what I am doing with agile in organizations, it gels with what I am doing in my volunteer work as a Baha’i.  It gels well with my limited media-filtered understanding of what is going on in the world of ecology, economics, and politics.

The Age of Interactions is characterized by

unlimited possibilities… unleashed for the ways individuals and organizations can connect and work with one another. These interactions have profoundly changed our world, presenting both a set of challenges as well as providing new opportunities.

This means that ways of working with these connections (skills, processes and technology) are going to become the keys to unlocking the potential of this Age.

I Disagree

Mr. Alberts claims “Agility is a latent property, a potential that remains dormant until it is manifested and its power released.” (p. 9).  This is incorrect.  Agility can be and is an active property, not latent.  Agility is manifested actively by running short-term experiments, options analysis, executing work using just-in-time principles, and systematically incorporating experience into a body of knowledge and habits that further enhance Agility.

Thanks to Dan Mezick for the link to this excellent paper via the PMIAgile Yahoo! Group.

OpenAgile is a system that helps individuals, teams and organization deliberately build the capabilities to demonstrate Agility, regardless of industry, affiliation, or context.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Berteig
Upcoming Courses
View Full Course Schedule
Real Agility™ Team Performance Coaching with BERTEIG
Online
C$45.00
Jul 5
2022
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1795.00
Jul 6
2022
Details
Kanban for Product Owners [MicroLearning™]
Online
C$149.00
Jul 7
2022
Details
Real Agility™ Team Performance Coaching with BERTEIG
Online
C$750.00
Jul 11
2022
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning]
Online
C$1795.00
Jul 12
2022
Details
PLAT SESSION: Agile Sprints for Managing Businesses
Online
C$0.00
Jul 12
2022
Details
PLAT SESSION: Agile Sprints for Managing Businesses
Online
C$0.00
Jul 13
2022
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$149.00
Jul 15
2022
Details
Real Agility Management Track - Practitioner I (RA-MT-LA)
Online
C$7950.00
Jul 18
2022
Details
Real Agility™ Team Performance Coaching with BERTEIG
Online
C$750.00
Jul 19
2022
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning]
Online
C$1795.00
Jul 20
2022
Details
Kanban for Product Owners [MicroLearning™]
Online
C$149.00
Jul 22
2022
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$149.00
Jul 28
2022
Details
Win as a Manager (ML-WAAM)
Online
C$895.00
Aug 10
2022
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning]
Online
C$1525.75
Aug 11
2022
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1525.75
Aug 23
2022
Details
Win as a Manager (ML-WAAM)
Online
C$895.00
Sep 8
2022
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1525.75
Sep 14
2022
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning]
Online
C$1525.75
Sep 21
2022
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning]
Online
C$1525.75
Sep 27
2022
Details
Win as a Manager (ML-WAAM)
Online
C$895.00
Oct 6
2022
Details
Win as a Manager (ML-WAAM)
Online
C$895.00
Oct 14
2022
Details