All you need is a bit of patience. Just be consistent in your message.

As many who have tried know, an Agile Transformation in a company is not always an easy process.  Although most people at first are keen to participate in the idea of “changing” the company culture and working environment to “something better”, many do not realize how much work it can actually be.

For some of you, you will be fortunate enough to be in an “Agile” environment already.

Perhaps you are using OpenAgile, or Scrum. You may be using a unique variation such as the Pomodoro technique.

For those of you that are new to the idea of Agile Processes, no matter what your flavor of framework or tool, there is something you will not be able to avoid.  Politics.

There is no getting around this.  Agile transformations are about change in an organization and not just change in one small section of the company.

Although many Agile teams start as “pilot projects”, even in such small situations, the effect on the departments or culture at the “edges” of even the smallest teams can start to cause ripple effects in an organization.

The first secret is to acknowledge and accept that this is going to happen.  Life will be easier for you this way. The job of any one assisting with an Agile implementation is to provide honest information and advice to help those who will be directly or indirectly impacted.

Don’t think you will be able to just hide in development and not be noticed.  Be prepared with slides, web site links, and open to talking about your processes and ideas with anyone who wants to know.  You must be transparent and open about what you are trying to accomplish.

OpenAgile for instance is defined as a “Learning System” because it deals with the realities that no one can work in a bubble and that more than just the “development team” needs to be involved in Agile practices for them to work.  The entire organization will be learning with you.

Scrum has a well defined set of guidelines to follow in regards to the development process and is ideal for new software development projects.

Lean is a more gentle approach to changing an organization in small, progressive steps.

Don’t kid yourself.  No matter how small the changes will be, there will be resistance from someone, somewhere, from where you least expected it.

The important thing to remember is what your goals are. The goal of the framework is an open and honest discussion between all those involved in your organization and general culture shift to a blameless, team based shift in thinking.

However, what is the real goal here? Happy customers, happy employees, and therefore, a profitable, progressive organization.  You must remember the purpose is not to make teams, but to make a good product for the customer. Sometimes, you may find it hard to remember.

I recently read The Wisdom of Teams: Creating the High-Performance Organization (Collins Business Essentials) by Jon R. Katzenbach and Douglas K. Smith. It clearly explains, with examples, how an organization with the courage to change their culture can really benefit from an overall culture shift towards Consultatative Decision-Making and team work based approaches.

Consistently, companies who simply “say” they have teams under-perform those that actually “just have teams”.  One type of company has them by edict or decree, and the other just has them because the culture is that way.  The ones with the naturally team based cultures do much better financially. Hmm..interesting.

Change is usually started by some kind of need to change because things aren’t working out “the old way”.

Buggy software, unhappy customers, late releases…Whatever the pain, the results are always a “desire to change”.

Those who have the courage to admit they need to change, should be applauded.  If you are new to Agile and reading this, please pat yourselves on the back for having the courage to learn more.

Now, it should be “easy” to stay on the path if you keep at it.  The act of Starting is the first big step. Congratulations!

One thing you will find as you proceed is a continual list of “it won’t work because of this”, “it won’t work because of that”.  But, hey, you’re not selling snake oil here.  You’re talking about people in an organization taking control of their work and working together for the best solution possible for the company and it’s customers.  Keep it simple.

Agile processes are just that … Processes..  They are not there to replace common sense. Agile is not a silver bullet to cure a company’s culture.  That part of things is still a human thing and will take time.  Please don’t think of Agile as a cure for a bad culture.  It is simply a way to help the culture to change.

To me at least, what is important is a consistent message.  I believe this is the key to helping an organization to be an Agile one.

Let’s take the Daily Scrum (for Scrum teams).   I worked with a company where the Daily Scrum was considered a waste of time and a nuisance for those involved (at first).

The daily scrum is a quick recap of where everyone on the team is.  For more information about the Daily Scrum, just do a quick search.  There is an abundance of information about it.  Try the Scrum Alliance for definitive information.

At this company, the owners and senior managers considered the scrum to be a nuisance. The senior developer of the team found it to be a hassle.  Then, after a few weeks of doing daily scrums, any team member could be asked by someone passing in the hall what was going on and that person could easily tell them what the status of the project was.  There are many other advantages to the scrum, but that’s not what this article is about. Maybe another time.

When I first started at this company, there was a weekly “developer meeting” which at first was the only way to exchange information.  It was generally 2 hours/week.  The team was now doing daily scrums and having small “mini-chats” (for lack of a better word) occasionally when needed.  Team members knew from the Scrums what was going on and who needed help with what and then self-organized to solve their problems and arranged “mini-chats” as needed to help each other out.

The “weekly 2 hour developer meeting” just became a thing of the past.  The team just stopped having them.

Waiting until the end of the week was far too cumbersome for something they could get from a 10 minute scrum and occasional “mini-chats”.  The team had unknowingly switched into a mode where they practiced regular consultative decision-making and regular re-assessment of their situation.

Then a remarkable thing happened.

One day, I was in a meeting, and the senior developer who at first was reluctant, banged on the window of the board room I was sitting in for me to come to the 10:00 AM Scrum which was 2 minutes away. I excused myself from the meeting and returned approx. 13 minutes later. The owner of the company said “Why do you do those daily meetings.  They are such a waste of time.  You have that big Developer Meeting every Friday”.

My response was “I’m sorry, but we don’t need to waste our time with that big 2 hour meeting every Friday anymore… We haven’t needed them for a few cycles now”.

What a remarkable experience!  In one quick step, and after considerable pain, not only was it evident that the senior developer embraced the Agile Scrum Meeting, but also the owner who was previously unsure suddenly came to realize that the team was far more effective than he knew and he hadn’t even noticed the shift.

The developer culture had changed to a more team based one without his knowing. All team members knew what was happening and Expected to be kept in the loop from now on.

The key is, keep doing it ! Be consistent.  If you’ve implemented a standard Agile practice, stick with it.

Be realistic though. There will be people who consider it to be “stupid” and there will be people who don’t want to participate.  As a new implementor, NEVER humiliate anyone in the process.  Simply encourage open discussion and ask everyone to contribute.  At first, people will be shy or nervous about this.  Over time, it will be the norm to participate.

The point is that as time passes, people and things change. The new processes will become Common Place and not so foreign and people will start to appreciate the fact their opinions are important and they have an impact on the bottom line of the company and the customer.  This is what drives people to be happy and succeed.

Then, with a bit of luck and perseverance, someone in a different department will say “Hey, I think that seems like a good idea. Tell me more”. “Do you think this Agile stuff might work in sales?” might be the kind of question you suddenly receive.  Do yourself a favor and be prepared for this with some links to a few Agile Methodologies at-hand!

This is your opportunity to introduce the new “culture” into a different part of the company.

With a bit of patience, others will come on board.  It will be a great experience for you once you have others helping out.

The day will come when someone will try and remove an Agile process somewhere in the organization and team members will lobby for their cause.  This is the day you will know…  I have succeeded with step 1… Getting started !

From here forward, it’s just a matter of consistently trying to improve things one cycle or iteration at a time, and watching things get better for the customers, employees, and of course, the stakeholders.

If I can give one last bit of advice.  Please do a bit of research before implementing something.  Ideally, you want the teams to come up with how to do their daily work, not yourself.  Let any process be the team’s process, not yours. Of course, if you have a new team to Agile, you will need to help them get started.

Consider your job as one of just guidance and coaching. That will work the best.

Review your environment carefully before deciding about methodology and do some reading or contact a coach about the differences. Should you be using Scrum, OpenAgile, XP, Lean, etc? Think about it carefully.  They have different levels of organizational change and are for different applications.  Use Wisely. :->

If you’re courageous enough and have an experienced Agile team, why not ask the team which Agile Methodology will work best for them?  I personally enjoy learning something new all the time. :->

Mike Caspar, CSM, OpenAgile Certificate Holder, ATPL

http://mike-caspar.blogspot.com

References :

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

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.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Awesome iPhone Tool: RectAce

Sure, the name isn’t the greatest, but this little tool is fantastic. Basically, every agile coach knows that you need to take photos of whiteboards, and every photo of a whiteboard either looks super crappy or needs to be processed after the fact to make it presentable. RectAce does it for you. It detects the edges of your whiteboard (or any other major rectangular feature in the photo), and then does all the color and contrast adjustments necessary to make it look nice. Here’s the link to the iTunes store for this app: RectAce.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Agile Planning Onion is Wrong

The concept is simple: there are six levels of planning in an organization, often represented as layers of a metaphorical onion. In the agile planning onion, strategy is the outermost layer. This is meant to indicate that it is the driver of all the planning in the inner layers, which have shorter time horizons, down to the daily planning that occurs in the Daily Scrum or the Daily Standup of the agile teams.

Culture is Missing

The agile planning onion is a reasonable metaphor, but it has a serious limit: culture is missing. Many of you will have heard the quote “Culture eats strategy for lunch [or breakfast]” (attributed to quite a number of different people – I’m not going to sort out who was the original). How do we represent culture on the onion? Is it a seventh layer on the outside? Maybe, but for most organizations, culture is not planned.

Single Loop Learning

The main problem with the planning onion is that it gives no indication that the planning cycles deal with anything but the product / business side of the work. This implication of single-minded focus gives us permission to limit ourselves to improving our products. This is learning, but it is limited. It is sometimes referred to as “single loop learning”. We make improvements, but never question our underlying beliefs, habits or goals. All improvement (and planning) is within the narrow guard rails of a product mentality.

Double Loop Learning

Culture both surrounds the planning onion, and cuts right through it (nice way to extend the metaphor!) The problem with a visual metaphor that does not include culture is it means that culture remains unconscious. As individuals we might, from time-to-time, find that the organization’s culture clashes with our own expectations, habits or beliefs. But other than this occasional dissonance, we are like onions in dirt – completely unaware of the dirt, yet completely utterly dependent upon it for growth (couldn’t use “fish in water” because that would have introduced a different metaphor – I’m trying for consistency).

In the best agile transformations, individuals, teams and organizations become aware of their culture and consciously work to change it. This is usually due to a strong clash between their current culture, and the behaviors, norms and attitudes of a embryonic agile culture. In Scrum, we find impediments and remove them. In OpenAgile we look for learning about product, process and people. This is, again, roughly speaking, double loop learning… it is learning about learning and applying this to our belief systems, our habits and our attitudes.

Transformation vs. Adoption

Those who share the agile planning onion model, probably don’t realize its limits. I would like to strongly encourage those who use this model to consider re-framing it in terms of culture and organizational learning, rather than planning. I’m terrible at diagrams – I hope someone out there will consider creating a new compelling Agile Learning Onion diagram to show that agile is about Transformation, not merely adoption of planning practices.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

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

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Five Tips for Distributed Agile Teams

Actually, this is six tips because my first tip is really about deciding to use distributed teams…

Some in-house studies that I have been privy to have shown 2-1 or 3-1 productivity difference between good co-located teams and “good” virtual teams. Creating a true, high-performance virtual team is incredibly hard emotionally, incredibly time-consuming, and costs a lot in terms of tools and travel. If this is being done for convenience of the team members or for cost savings, it’s a bad idea. The only good reason to have distributed teams is if there is a compelling strategic reason that trumps the hit you will take financially and morale-wise. (That was tip “zero”.)

That said, it is worth trying is to create an environment as close as possible to what you would get with a co-located team. To do this, here are some things to try:

1. Set core hours (at least 3 contiguous) every day when everyone on the team, regardless of time zone, will be at work simultaneously. If you have a globally distributed team, this will mean that some team members will have to make an ongoing personal sacrifice to be available. This sacrifice should be compensated financially. Avoid rotating the core hours in the mis-guided idea that it is better that everyone is uncomfortable some of the time vs. some being uncomfortable all of the time. It is much easier for a team member to get used to a consistent schedule and although initially there will be discomfort for some team members, they will (relatively speaking) get used to the new schedule.

2. During core hours, use a good video conferencing tool (e.g. Office Communicator), in an always-on state for all team members – be in the same space at the same time. Cameras should be set up so that it is possible to see an individual’s facial expressions, yet also to allow that person to move around and still be in-view. The video conferencing tool should have good full-duplex audio so that no one ever gets cut off because someone else is louder.

3. During core hours, all team members agree to forego the use of headphones or anything else that would prevent them from instantly being aware of something happening with any of the other team members. Again, for some people this might be quite a sacrifice. The idea is that communication is paramount for agile teams and anything that isolates one team member from another will hinder communication.

4. Have a live update task tracking tool that all team members use. (Most agile team management tools that I am aware of do not work because you have to refresh to see updates. Cardmeeting.com is a decent virtual wall that has live updates.) Any task-switching should be visible on this tool either through a color change, an audible cue, or a movement. So if I complete a task and start on a new one, everyone else should notice this immediately even if I do not actually say anything. The team members should get in the habit of using this tool even outside core hours.

5. Have a second (or third) monitor for every team member that is dedicated to the always-on communication tools (video conferencing, task tracking). These always-on tools should _never_ be covered by anything else. All the real-time communication tools are useless if they are not constantly visible. If your team members currently have two monitors, then get them a third for these tools. There should never be any excuse for a team member to hide these tools.

Basically, these suggestions are designed to maximize the quality, bandwidth and minimize the latency of communication among the team members. If you have a distributed team, and you try these things, please let me know how it works for you!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

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.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

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!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail