Category Archives: OpenAgile

Where should I sit?

Posted on by
Reply

Inevitably, there will be some change to your team.  Someone will leave or perhaps you will have new members joining you.

Either way, you will be asked the question “Where should I sit?”.

Do not take this question lightly.  You have the opportunity to make significant changes with the addition or departure of a team member.

There are many different types of personalities in a team.  Because of this, you cannot realistically expect the same personal interactions between people sitting next to each other.

More importantly though, it is your responsibility as a Scrum Master, Mentor or Coach to consider the positive adjustments which can be made during this great opportunity for change.

A simple example to get you thinking about this could be….

  • You have a developer sitting at an end station with a slightly restricted view from the rest of the team.
  • This team member does not ask for help when he or she needs it.
  • You will be adding a developer to your team.

Trying to talk to the developer who does not ask for assistance, may help.  However, why not consider using this opportunity to solve this problem in a different way.

If the developer is moved to a more central location, they will not be as separated from the group.  Perhaps this would give them more opportunity to ask for help, increase their communication level with peers, and if you are lucky, the other team members will more easily recognize that this is happening an spur this person on to get them to ask for help.

So, where do you put a new developer ?… Certainly not off at the end by themselves.  The new person will feel isolated, and will have a harder time integrating.

The team is already a very close unit and has gone through the team development stages of Forming, Storming, Norming, and Performing.  With the addition of the new team member, this cycle will start again and will make it even harder for them if they are on their own at the end of the seating layout.

Reminding the team of the four stages of team development before a new person comes on board can be a big help.  It reminds all team members of how hard it is to integrate new members and the likely result of the addition.

Many people can get attached to their desks or workstations.  Therefore, moving people around in a traditional environment can be a painful experience.  In an Agile team, life is about change, adapting, adjusting to what is happening and making positive changes to improve productivity and enjoyment.

As team members move locations, they will learn different skills and ideas from the person sitting next to them.  It will also be common place to adjust as necessary.

Changing team member locations also helps change things up and gets rid of complacency.  A danger for an Agile Team is no longer attempting to make changes and progress because everything is “fine” or “perfect”.  If you are hearing these things from your team in Review or Retrospective meetings, perhaps it is time to change desks just to get change happening again.

There may be other personality or non-team type things you wish to address.  Instead of bringing that person into an office and talking to them, you could solve things by simply changing desk locations.

Better yet…..  If you have a team that has embraces and practices Consultative Decision Making, why not ask the Team where the new person should sit to be most effective!

References:

Scrum Master – Scrum Alliance
Consultative Decision Making -Open Agile Institute
The four stages of team development -Wikipedia.org

What if your first cycle ends up with zero story points completed?

Posted on by
2

I recently introduced a small software development company to the ideas of Agile development, the culture of Agile, and of course some of the fundamentals of working in incremental steps.  We focused specifically on OpenAgile.

They started their first cycle with great enthusiasm and with as much attention to detail as possible, but still ended up completing zero story points in their first cycle. Is this is a disaster ? The short answer… NO.

The company has gone through two major releases based on non-agile methods with limited success. One of the owners of the company has been a long time friend and we discussed doing some Agile training with his employees to “see how they felt” about learning about OpenAgile.

There were no commitments made to it. The idea of “Hey, let’s learn about this and see if it’s right for our organization” was the goal. All the team members were told that the company was considering (with emphasis on considering) switching to OpenAgile and would not do it if everyone didn’t feel like it was worth the effort and made sense for them. It was stressed that OpenAgile is not a silver bullet and may not be right for them. The effort was purely exploratory in nature.

As this company is in software development, Agile development easily made sense for them. They were so excited by the OpenAgile training, the developers and the owners decided to immediately abandon their existing plans for development and refactor.  The fact they felt they could do this shows true management leadership and support for the process.

I have to congratulate my friend for his courage in supporting his team.

The team determined that they were working on functionality which would not provide the greatest Return on Investment and decided to adjust their priorities accordingly.

A great deal of our time was spent during the training on the ideas of Consultative Decision Making and encouraging openness between those involved in the process. All team members are encouraged to be open about their opinions during planning and if they find something wrong during the cycle, to speak out.

I find that having management and stakeholder support and encouragement in the process is almost mandatory for Agile to work. Without the understanding from the owners of the company, the culture required to make it work will inevitably cause friction “around the edges” of the Agile team.

We spent time on the concepts of ROI (return on investment) and how to apply it to estimating, planning, re-estimating, and selected work. In using OpenAgile, we want to work on the tasks that give us the biggest value over effort factor or ROI.

We followed the OpenAgile syllabus. As an OpenAgile trainer and mentor, I had easy access to material to teach in an organized fashion.  Their environment is complicated by owners in multiple cities and developers in 3 different cities including an overseas component.

Openness about the potential pitfalls of remote teams made a big difference to the attitudes of those taking the training and the final outcome. Learning OpenAgile, Scrum, XP Programming, or any Agile process is difficult enough without adding the component of two remote teams and overseas development.

Many people leave their OpenAgile training realizing that it is a very effective framework and are anxious to get rolling. Because this company and the team decided to continue with OpenAgile, they started the preparations for the first cycle to begin the following week (after a long weekend break).

The cycle started, cards were created as Story Points, and the work began in earnest. They had many surprises. I had been unavailable through their first cycle and had very little ability to keep up with how they were doing because of a new Scrum Team I was working with. In retrospect, I am glad I was not there to give advice. They did fine on their own :->

In true Agile form, they figured out on their own what was going wrong and when I talked to the owner several weeks later I found out that they had already determined their mistakes.

The team was actively taking steps to improve the next cycle.

If senior managers encourage the right environment and let the team self-organize… you know what.. they likely will :->

Things that went poorly

  • Two days into the cycle, some of their overseas developers went “to visit family”. They did not realize at the time, this was local code for “going on holidays”. I heard from the owner later that if they had not asked why they did not get responses to emails, they would not have known the other developers were away.
  • The Stories were Too Big. Because of the combination of the new way of doing things and the excitement about how much could get done as an Agile team, the team bit off more than they could chew.
  • Attempts at Test Driven Development did not go well.
  • The first two week cycle stretched to 3 weeks because the team didn’t want to have Zero velocity as they felt this was a failure
  • One display bug crept into the first demo related to two different ways of refreshing data on the screen

Things that went well

  • The team talked regularly about how they were doing and worked on regular status updates to determine where they were during the cycle.  This is also how they found out about the missing developers.
  • The owners and managers had an active involvement in helping to remove obstacles.
  • The team found an intriguing way to determine how many story points they could actually commit to in future cycles.
  • The team figured out how to deal with code sharing and peer review type issues related to being at opposite ends of the earth.
  • The team stayed together and focused on the goal of creating potentially deliverable product
  • They were able to successfully work on two simultaneous streams of work on different parts of the system.
  • During the demo, the team was able to demo functionality that could potentially be brought to a customer after only two cycles.

Summary

I had a discussion with the owner recently and he told me they all sat down and realized their mistakes of their first cycle. They consider OpenAgile to be a success.

The team was so worried about not completing story points, they considered it to be a failure to not finish at the appropriate time. You need to let newcomers realize that not completing all the story points of the first cycle may happen.  This can be compounded by added complexities of your working environment or project.

Since they were pushing to get the points completed, they were sacrificing quality. They were rushing because they knew they had gone past the end of the cycle and it was causing more problems each day it continued. Thankfully, they stopped the cycle and decided to do the right thing and demo where they were and talk about their progress.

They simply took on too much work, didn’t account for all the other overheads of a new team setup and issues that would take place with their remote environments. This did not mean failure. They learned how to re-organize themselves for future cycles.

With the support of the owner and a little bit of moral support from myself, the team realized they had accomplished a great deal already in their first cycle.

They realized they need to put some better controls on the holiday schedules of the remote teams overseas or at a minimum find out what is expected in this regard.

The team realizes it has a deficiency with Test Driven Development and is working on plans to allocate some time for training on this very important task. Perhaps their one bug from the first demo may not have been there with Test Driven Development in place. They will continue to work toward improving this.

One of the great things to come out of their first cycle…. A potentially deliverable product within the first two cycles!

When I reviewed this with the owner he told me the completed work is already faster and better than their previous system which took 5 years to write. Considering the remote component they are dealing with, this is truly great news for them. Their first cycle has produced software which can now simply grow organically.

Some advice here which I shared with my friend.. Make sure that you have at least one story that can be finished in the next cycle, no matter how small.  Consider it of huge Value to the Agile process.

You need to provide some positive feedback for the team members now.  This does not mean the team should agree to less work than they think they can accomplish. Simply encourage some work that can be completed to be included in the next cycle.

For my friend, although they completed zero story points in the first cycle, they are happy to know that if they just adjust the size of their stories for more attainable results and use what they learned from the first cycle, OpenAgile will work out well for them.

The concepts of Consultative Decision Making, Continuous Learning and the Learning Circle allowed them to truly excel and will allow them to continue to do so into the future.

They are looking forward to shipping their new product in record time :->

One comment that was made to me was something along the lines of “Hey Mike, this reminds me of when we used to work together in the garage when we started the company. We all worked together on whatever needed to be done. That’s what made us successful in the first place.”…. Hmmmm.

Mike Caspar, CSM, OA2/5

References: OpenAgile - www.openagile.com

Remember that Agile is about Quality and Business Value

Posted on by
1

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

WHY? Such a powerful question

Posted on by
Reply

Recently I was watching a situation with a development team where a very important question seemed to be forgotten… WHY ?  This got me thinking about the countless times I have seen work done for no apparent reason than it’s “On The Wishlist”, “We have a card for it”, or “Because Customer Service Says So”.

Many times I have seen features get created where at the end of the release, the final user of the feature says, “Oh, we haven’t needed it to do that for about 3 months now”.  This part of the requirements is long gone.

This brings me back to Waterfall Methodology and something I would expect to see. With it’s linear approach to the Software Development Cycle, it is almost to be expected that there will be some waste of this nature.  This is not to say that Waterfall is never appropriate.  It is just an expected part of the process if you have a long development cycle.

However, using an Agile Methodology such as Scrum or OpenAgile, this should simply not happen.  Agile methodologies are based on Communication.  This communication is paramount during the Sprint or Cycle but is absolutely mandatory during the planning meeting. A team cannot simply be given a list of instructions to follow.  The team needs to understand what their Goal is.

In Scrum, the Product Owner is responsible for guiding the team as to which features should be queued up next based on Return on Investment (which generally means actually needed).

In OpenAgile, the team has a similar approach of consultation with the “end user’ and the planning of work based on Return of Value, and plan appropriately.

Although in Scrum and OpenAgile, there is discussion about Return on Investment, Value, bug free code, Test Driven Development, etc. there often appears to be little discussion about the idea of why we are doing something.

User Stories, if done correctly can significantly improve this problem because the “story” needs to have a goal as to who benefits.  We are doing this Feature for this “x” to get this benefit.

It is however, the responsibility of a Team to ask “Why would someone want to do this ?”, or “Why are we updating this information in the first place”. Often, the insights are very revealing.

Let’s take a simple example.

I the late 80′s, I was working as a developer with a company where the company’s approach was to provide the developers a “requirement” , choose a developer and send them off to do the work (pre-Scrum days).

The developer was to modify a Stored Procedure to go through a table and update every 3rd record in the table to be 50% higher.  It was a fairly complex procedure and a developer at this company spent almost a week re-writing the procedure and getting it implemented. The development team sat down with the engineers and customer and developed a method of testing and verification, backups of the database were made and the implementation work began.

No one asked Why.

Several weeks later a similar request was made in a different part of the system. I spent some time with the developers and encouraged them to ask Why the first modification was made.  The answer was “That is what Sherry said to we should do.  The customers are yelling and this is what we need to do to fix it”.

Those of you using Scrum or OpenAgile are probably already cringing and thinking.. Gees… you could write a book just on this one paragraph alone.  I’ll leave that for another day :->

The actual problem was there was a different part of the system which updated the tables based on Quarterly Results.  This was the actual reason every 3rd record in the table was wrong.  That procedure was incorrect and shared by other parts of the system.

If someone had not stepped in, this cycle of fixing the by-product of the defect could have gone on for many more months.

I convinced the owner to change the procedures to allow the developers to ask questions as a team before work was queued up. I simply asked for this one simple right.

A few months later, the overall bug rate of the application went down, customer complaints went down and the development team started to feel engaged and part of the process.  It was a different place after that.  People enjoyed working there.

As part of the planning stage of your Sprint or Cycle, please consider asking questions such as

-Why are we changing the Field Size from 80 Characters to 250 Characters ?
-Why should the system need a procedure to update these types of records .. Doesn’t the system do it properly ?
-Why would we want to force through Credit Card Transactions without the CVV Code (the security number) ?
- Why are we making a whole new authentication system ?
- How did this become a requirement ?

This type of question is not intended to be a confrontational thing!  Often those requesting the features may feel that you are being confrontational.  Remain calm, and make sure to let the requester know this is a standard part of your process and not a question of their power or knowledge.  The goal is to get knowledge, and not to figure out who is right or wrong.

After discussing it with the person, you may find they do not have a true understanding of why they are requesting the feature or change.  It is possible the idea of what or how to do it will change just from the communication alone (which is when you want it to happen.. not after it’s done).  The discussion may also allow the product to be better than they originally envisioned.

OpenAgile has a term called “Consultatative Decision Making”.  It is the idea that decisions are made based on consultation and discussion with all those involved that may have valuable input to making a decision.

Scrum also values discussion and communication as a fundamental part of Development.

The FIRST value of the Manifesto for Agile Software Development is “Individuals and Interactions over processes and tools”

In the case of the example above, we chose to fix the stored procedure which was creating the bad data and wrote a one-time script to adjust the corrupted records. We never had to revisit this problem again.

It sounds simple enough, but the basic premise of WHY is absolutely mandatory to this process or all decision making will be based on following instructions blindly with no sense of ownership by the team.

References :

Scrum – http://www.scrumalliance.org
OpenAgile – http://www.openagile.com
Manifesto for Agile Software Development – http://www.agilemanifesto.org/

Why is hardware being forgotten by development companies?

Posted on by
Reply

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

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

Posted on by
Reply

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 :

Stress-Free Priority Meetings using Planning Poker Cards

Posted on by
1

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

Upcoming Agile Seminar – March 23-25, 2011 in Markham near Toronto

Posted on by
Reply

Berteig Consulting has an upcoming Agile PM + Certified ScrumMaster (CSM) + OpenAgile + Kanban training seminar on March 23-25, 2011 in Markham. It is facilitated by Mishkin Berteig! This seminar counts towards three different Agile certifications. Go to: http://www.berteigconsulting.com/ScrumCSMOpenAgileKanbanMarch2011MarkhamTorontoOntarioCanada for more information.

Coaching Agile Teams – Interpersonal Skills a Must

Posted on by
1

I know that coaching is hard. It requires many skills including: facilitation, encouragement, experience, an openness to learn, and interpersonal skills. I have learned that many believe that good Agile training and coaching requires technical skills (in a software development environment) above any other ability. I do believe that technical are important. However, those skills can be learned and advanced within the time with a team, training and/or coaching.

I have met many people that would like to train and coach. The one thing that seems to be lacking in many of them that would like to be effective is strong and well-developed interpersonal skills. I mean skills that include the ability to relate well with others, the ability to walk shoulder-to-shoulder with others as they learn and practice the art of being Agile, and the ability to observe and offer suggestions with humility.

Technical skills can be learned over time. Interpersonal skills are much harder to learn and have a much deeper impact on those that are being trained and coached. The second set of skills help teams develop, aid management in becoming part of the Agile transformation, and allow individuals to become partners in the process of culture change.

Wouldn’t you want an Agile coach that has integrity, wisdom, and humility over one that is proficient in .Net, Java, and can build databases?

Agility, the Age of Interactions, and the Military

Posted on by
Reply

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.

Case Study: Agile Process and a Twist on “20 Percent Time” for a Self-Organizing Volunteer Team

Posted on by
Reply

Cross-posted from the personal blog of David D. Parker: A Changemaker in the Making

I am engaged in a learning process with a charity that has undertaken to implement a new model of volunteer coordination based on OpenAgile, an open source agile method.  We recently held an orientation with our new volunteers.  In the hopes that this information will be useful to others who are trying to innovate on their  model of volunteer coordination, here are the instructions I shared with the volunteers.  In summary, they cover our process for sharing tasks, the tools we use to communicate with each other, and our use of what we are calling “60/40 time” a twist on Google’s “20 percent time“.

ORIENTATION INSTRUCTIONS:

I. Agile Volunteer Team Process

We are all here to support the charity. We are inspired by its mission and goals, and we want to help in a way that draws on all of our abilities, knowledge, skills, and creativity.
Our team uses a specific system for producing valuable results. We work in Cycles of 5 weeks. The charity’s staff talk with the stakeholders and decide what steps are necessary for accomplishing the organization’s goals. Each one of these steps, called Value Drivers, add up to providing value for the stakeholders once they’re delivered. The staff also decide the priority order for completing the Value Drivers.
In week 1 of the Cycle, there is a planning meeting with all the volunteers who are committed to doing work during the 5 week Cycle. All volunteers are urged to attend and participate.
  1. The meeting begins with reflecting on the results of the previous Cycle. These observations and lessons are an important part of the planning process.
  2. Next, the team of volunteers works together to create a Cycle Plan by taking the highest priority Value Driver and breaking it down into tasks. Tasks are represented by sticky notes on the wall.
  3. Third, the volunteer team counts the number of tasks needed to complete the highest priority Value Driver. If the past Cycle showed that the team can complete more tasks, then the team takes the next Value Driver in the list and breaks it down into tasks. This process continues until the team makes a unified decision that it has taken on the amount of work it can actually accomplish.
  4. The last part of the meeting is commitment. Everyone shares the responsibility for completing the Value Driver (represented by multiple tasks) by the end of the Cycle of work. Therefore each volunteer must truthfully commit to completing the work. If a volunteer is not comfortable committing to all the work on the task wall, then some tasks must be removed until everyone is able to commit.
In week 2, 3, 4, and 5 of the Cycle, the team of volunteers complete the tasks in the Cycle Plan (aka “doing work”).
  1. Volunteers are free to take whatever task is of interest to them. If they need more information about the task, they ask the other volunteers or the staff for details.
  2. When a volunteer begins a task, they sign their name on the bottom of the sticky and move the task into the “in progress” column.
  3. When a volunteer completes a task, they move the task into the “done” column.
  4. There are weekly conference calls where all the volunteers check in. They answer 4 simple questions
    1. What did I do last week?
    2. What will I do this week?
    3. What did I learn/observe?
    4. What obstacles, if any, are affecting my ability to do work?
  5. New tasks can be added to the wall based on any of the volunteers’ observations, obstacles, clarifications, questions, urgent new tasks, etc. If you add a new task to the wall, add your name to the bottom of the task, so that other volunteers can know who to go to for questions. Note that these new tasks must also be completed by the end of the 5 week Cycle.
At the end of the 5 week Cycle, the team presents the valuable results it has produced to the charity staff/stakeholders. Any insights, observations, corrections, etc. are factored into the next Cycle Plan.

II. Communication Tools

Over the time we have worked together, the volunteer team has decided to use a few tools to help us communicate. The main tool is the task wall and sticky notes. The secondary tool is a shared Gmail account.
NOTE: This list of instructions is a working, evolving document; it is not set in stone. Volunteers are encouraged to work together and adapt the way we do things to create a system that works well for all of us.
ACCOUNT INSTRUCTIONS:
  1. Login and read new messages
  2. Emails in the Inbox means there is work to be done (if the task is complete, archive the email to remove from the Inbox aka the To Do List)
  3. Apply Labels – Gmail doesn’t use folders; it uses labels instead. Apply labels to emails to assist other volunteers with how to treat the content of that message.
  4. Write up volunteer tasks for the task wall (Note: Label as “Task Written & Posted”)
  5. Get work done:
  6. Move the task on the wall to in progress
  7. If the task came from an email, label the task with your name
  8. When the task is complete, label as “Task Complete” and archive the email so it doesn’t appear in the Inbox
CURRENT LABELS:
  • ??? – this means more information or context is required to understand the request –> ASK QUESTIONS, or get help, to complete the task
  • By Volunteer Name –> This means the task/email is in progress; A volunteer labels the email with their name when they accept responsibility for a particular task
  • FYI (For Your Information) – these are emails that contain information that is relevant to volunteers, but does not necessarily require action be taken. If action is required, write up a task and post it on the wall)
  • Task Complete – Use this to label When a task is complete; archive the email so it doesn’t appear in the Inbox
  • Task Written & Posted – apply this label after you write up the task and post it on the wall
  • Social Media – these are emails that apply specifically to social media like Twitter, Facebook, etc.
  • Website – these emails are relevant to website updates

III. What is 60/40 Time?

There are many reasons why people volunteer.  Here is a short list that comes from Molly Schar’s article Making the Most of Nonprofit Volunteers:
  • Belief in the mission of the charity
  • Desire to “give back”
  • Meet new people
  • Make new business contacts
  • Invited or inspired by another volunteer or staff member
  • Improve resume
  • Learn new skills
  • Benefits such as free events
We want all of our volunteers to get the most out of their experience here. Rather than insisting that every moment of a volunteer’s time be spent on completing tasks on the wall, we ask you to split your time 60/40. We want to give our volunteers freedom to spend a large portion of time doing things that satisfy their motivations while still providing value to the organization. For example, if someone has an interest in building skills in using social media, but there aren’t currently any tasks on the wall related to social media, the volunteer would be encouraged to use 40% of their time using social media to benefit the charity. The remaining 60% of the time is essential for delivering other important results to the organization. We aspire to having a trusting environment, so it is up to you to monitor how you’re spending your time. During progress updates, all volunteers are encouraged to share what they’ve accomplished during their 40% time. This will help other volunteers to learn what motivates their teammates and will give the team information that can be integrated into future Cycle Plans.

Case Study: OpenAgile for Charity Volunteer Management

Posted on by
Reply

Cross-posted from my personal blog: A Changemaker in the Making

For the past several weeks, I have been helping a small charity solve a dilemma. Because the charity is well-recognized for their good work, they regularly attract volunteers who want to help. Unfortunately, the two overworked staff members are too busy to recruit, train, and manage them. My approach has been to use OpenAgile, an open source system for delivering value to stakeholders, to implement a few simple techniques to help them.

There are several aspects of OpenAgile that fit very well for managing volunteers:

1. Self-Organizing Behavior

This means people “volunteer” for tasks instead of doing them based on a tightly defined role or having someone tell them what to do. This frees the staff from having to assign work. Instead, they identify priorities and rely on the volunteer’s creativity and personal motivation to do the task in their own way.

2. Shared Responsibility for the Workload

When there is more than one volunteer, they work in a team and share the responsibility for the workload. The team of volunteers discuss the priorities of the organization, and decide among themselves what tasks need to be completed. Then, they create and commit to a 1-2 week short-term plan that will deliver those results. Finally, they come back after the 1-2 week period and reflect on what they accomplished.  This pattern of action, reflection, learning, and planning is one of the Foundations of OpenAgile.

3. Visible Tasks

This means that all people doing the work should be able to see what tasks needs to get done, what is in progress, and what tasks are done. One technique that co-located teams often use is simply posting tasks on a wall using sticky notes. (Check out my OpenAgile Task Wall Prezi) Another cool idea is Card Meeting which works on the same principle, but it can be useful for distributed teams.

4. Learning Manifesto

The emphasis on learning is perhaps the most important aspect of OpenAgile that aligns with the needs of volunteer management.  The Learning Manifesto states that “Learning is the key that unlocks human capacity.”  Volunteers are drawn to an organization because of its vision but can get pushed away when they feel they’re underutilized or not able to contribute in a meaningful way.  By making it explicit that the volunteer is primarily accountable for learning, the organization creates a safe space for experimentation and innovation.