Agile Ramblings

Home » Adoption

Category Archives: Adoption

The Agile Manifesto is NOT a Buffet

December 5, 2013 12:02 pm / Leave a comment

I’ve recently stumbled upon two blog posts that got me thinking about agile adoptions and why they might fail (not in a safe way).

First there was this post that I saw because it resonated with a colleague and he shared it.

http://inline-lambda.blogspot.ca/2013/11/agile-b2b-and-beta-conundrum.html

I don’t know Guillaume and I’m sure he is a very nice guy, but the post struck me as from someone who didn’t understand the Agile Manifesto and was confusing it with the prescriptive guidance in the Scrum Guide or the guidance of The Lean Startup.

And then I saw a post from my friend Dylan Smith starting a blog series about “Why Does Agile Fail”.

As I was reading these two posts, I started asking myself Why are these authors making these statements? Why are they observing these effects? The way that I’ve understood the Agile Manifesto and its intent, you shouldn’t see these effects, at least not for very long. It struck me though that this is a story that I hear over and over again.

Then I had a light bulb moment.

We often talk about an “Agile Buffet” as a set of tactics or practices we can pull from and use as best fits within our organization. I like this. As a passionate Kanban Method practitioner, the idea that we’ll continuously discover problems opportunities for improvement and that we’d want to leverage past industrial learning is a core philosophy for me. But the Agile Manifesto is NOT a buffet. We should not pick and choose which of the values and principles that we will follow and aspire to. They are all necessary ways of thinking if we’re going to pull our industry out of the dark ages.

Now I am not suggesting we shouldn’t be finding the best way to, in context, live up to those values and principles. We should be very disciplined in What we pull from the Agile Buffet and When we pull the improvement. This is where a Kanban Method approach to continuous improvement is enormously beneficial. With a functioning kanban system, we have data that allows us to make informed, economically sound decisions about improvements and a mindset that we are going to improve incrementally and in an evolutionary manner. We are actually slaying a software development dragon with a 1-2 punch of Agile Manifesto thinking and Kanban Method thinking. We’ve got something guiding us towards what a successful software development team would behave like (Agile Manifesto) and we’ve got something showing us how to get to that goal in a humane, intelligent, and economic manner (Kanban Method).

 

Final Thoughts

I would like to encourage you to go read the Agile Manifesto again and to go read about The Kanban Method. They won’t tell you how to do things, but they are telling you what you should aspire to do. Now with that in mind, go and look at the Agile Buffet. Read the Scrum Guide. Read the kanban blue book as well as look at case studies from teams that have used the Kanban Method. This is your buffet of tactics that can help you solve your problems. Start pulling from this buffet of industrial learning. Develop a capability to understand what works for you and perhaps more importantly what doesn’t.

But please remember, these value systems are not a buffet and you don’t get to pick and choose from the values and principles they provide.

The Kanban Method Is A Vehicle – It Is Not A Destination

August 14, 2013 9:13 am / 4 Comments on The Kanban Method Is A Vehicle – It Is Not A Destination

Wow! I just got back from #Agile2013 in Nashville and I have to say it was a great experience and my brain is overflowing with ideas! Which is always good for blogging. Open-mouthed smile

One of the things that occurred to me while I was there was the seeming surge in the competitiveness amongst methodology practitioners. There were numerous tweets and blogs, sessions and conversations all discussing the pros and cons of one method versus another.  Here are just a few things that I’ve seen… (FYI, I pick on everyone equally. Let’s call it an evolutionary fitness test.)

http://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed/

 

http://www.nofluffjuststuff.com/blog/alan_shalloway/2013/08/announcing_the_3rd_generation_of_lean_agile

http://www.netobjectives.com/blogs/why-net-objectives-supports-scaled-agile-framework-safe

 

http://www.djaa.com/kanban-alternative-path-agility

http://www.djaa.com/kanban-anti-safe-almost-decade-already

 

So we have a lot of posturing and positioning, and I actually don’t mind that. With noise comes interest, with interest and curiosity comes exploration and learning, and we can all grow. I hope though that by reading this blog and the other blogs and by exploring the topic, you gain a greater understanding of the items under discussion. It was with this intent that I had a really good conversation (or two) with Al Shalloway and Nayan Hajratwala about SAFe and the current thinking about The Kanban Method and Kanban/kanban in general.

So we were hearing the noise, exploring the enemy, probing for weaknesses and then trying to sway the enemy to our side. ;P

Today I had a realization about the experience. I learned about SAFe. I learned more about Scrum. I expanded my own understanding of The Kanban Method and kanban in general and I discovered more refinements to my thoughts when having this conversation! The Kanban Method, as David has been saying and said in the post above, is not the enemy of SAFe or Scrum or any other practices-based methodology that is a manifestation of the Agile Manifesto. It isn’t even comparable. It isn’t an Agile-practices based methodology at all, which is why David (and many of us at LKU) have been saying that The Kanban Method isn’t an Agile methodology! It is the vehicle that GETS you to Agile, wherever that may be for you! It is the vehicle that you use to encourage a collection of weird-acting individuals (people in an organization) to do something, such as adopt a bunch of agile-influenced tactics that might be described within any of the other practices-based methodologies!

Let me draw a picture!

image

We all start on these process adoption/organization transformation/improvement initiatives from a current state. Very often we can’t even describe the current state, but that is where we are. And very often, we can’t accurately describe the desired end-state, but let’s suggest for a moment that we can. So we know where we are (maybe) and we know where we want to go (maybe) but how to get there?!?! Some folks would have you believe you can jump there by telling the organization to put something in place.

image

I don’t mean to pick on Scrum. I like Scrum when it is the right fit. But it is frequently adopted blindly and prescriptively because it provides a lot of guidance on specific practices. But what if Scrum doesn’t fit? (Are there any DevOps people reading?) What if Scrum doesn’t help with the capability that you’re interested in? Or what if you’re problem is a scaling it out problem, which Scrum has troubles with. Good news! SAFe is right around the corner!! And virtual kanban systems! And Random Acts are there too!!

image

These are all methodologies with some great tactics to use for organization improvement right?! If you just tell everyone to do Scrum, SAFe, virtual kanban, or random stuff (heros, cowboys and smart people), we’ll achieve the improvements we’ve been struggling to get for the last 50 years in our industry!! But I heard this awesome comment from Linda Rising at #Agile2013 during her talk. I forgot to attribute it to her in my tweet though!

This is part of the problem with prescriptive approaches to process adoption. And unfortunately, Scrum and SAFe as described are easily prescribed. I’d even venture to state that the authors and evangelists of these methods want them prescribed. “If you do this, everything will be ok.” Of course they will not admit that they want you to blindly adopt all of the tactics, but in my opinion, the way those methodologies are described and evangelized, that is how it works out in the end.

And never mind that we still don’t really know if the methodology that we’ve selected will get us to the desired improvement given the context in which we are applying the methodology! Do the people in your organization want Scrum? SAFe? virtual kanban systems? Will they be able to pick up all the necessary practices? Apply them properly? Will the organization have the maturity to get through the hard parts? What if you’ve picked the wrong method? And what if the actual end-state option that you need isn’t the one you thought you needed at the start?

image

 

Has this happened to you? Have you seen this happen?

I want to reiterate at this point, I don’t think that the practices and tactics described in Scrum are bad. I don’t think SAFe tactics are inherently bad. I don’t think that “Kanban is so easy” crowd (proto-kanban or basic virtual kanban systems) are bad. It’s just going to be harder, longer, and more costly to get to an end-improvement than it should have been. You’re increasing the chance of your improvement initiative being interpreted as a failure, or being aborted early. Or leaving improvements undiscovered!

Another thing that I think is really interesting is that most of the practices-based methodologies describe themselves as an end-state. Like there is no more to learn and no more reason to grow in your context. What if the discovered end-state is a healthy, functioning Scrum implementation. Is that the end? Is there no where else to improve? What guidance does Scrum give you if you find an improvement that is counter to a described Scrum tactic? Or SAFe for that matter? Should we have end-states?

image

 

I think we are far better served trying to create an organizational capability to identify improvement opportunities and  use any/all available tactics that we think will move us towards the desired improvement, once we know what the specific problem is. I think we are better served by creating an organizational capability to understand the attributes of the work that we do (volume, frequency, size, complexity) and understand the capability of the organization to execute that work. And I think that we are better served by facilitating the creation of a kaizen culture within the organization that will continuously seek out opportunities to improve because then the people own the problem and the improvement!

I want a vehicle to get me to my currently planned destination!! I want to be able to make informed decisions and change the destination! I want all my peers to dynamically guide their team to the next improvement that is discovered in the context of doing the work! And I don’t want to limit my destinations! I want to know that I’m making progress!

So we know you’re organization is ‘here’! Sounds silly when you say it that way but even if you can’t describe it, you are where you are. And there is some value in describing where you are because it will make progress measurable and discrete instead of abstract or qualitative. And we know that we need to be… faster let’s say. It should be more elaborate than that but bear with me for a moment. Now we have to convince everyone involved to paddle in the same direction!

What can I use to do that? Will Unit testing help? Will team structures help? continuous delivery? project roll-up techniques? Will any of these specific practices help me create an environment that causes groups of people to understand the problem, understand the capability, formulate a plan to improve and then determine if the execution worked? I do not think so. Are they all good things? YES! Unequivocally! Are they good things for everyone? All the time? No.

The Kanban Method will foster these capabilities for you because that is what it is designed to do. It is not designed to make you code faster or with higher quality. It will help you understand the cost of poor quality and then allow you to experiment with quality improving tactics like Unit testing/TDD/ATDD/BDD/xDD. Will it help you deploy your application faster or sell more units of your product? No, you have to use tools or LeanStartup for those kinds of things! Will it help you create a kaizen culture within an organization? Yes, because that is what it is designed to do. Will The Kanban Method encourage you to adopt concrete practices from any other methodology? Yes. Can you use a SAFe tactic if it seems logical in your context? Yes! Scrum tactic? Yes! virtual kanban system? Absolutely!

Final Thoughts

I keep coming back to something that my friend Frank Vega has said numerous times.

“The greatest learning happens at the boundary of disagreement.”

It was because of the disagreement that Alan Shalloway and I have about how we should guide people that I had these conversations. It was because of the respect and curiosity that we both have that we continue to meet at this boundary.

It think it is important though to be clear and compare like things.

The Kanban Method is not an Agile Manifesto-inspired practices-based methodology like Scrum or SAFe. It is an approach that is intending to create a capability within organizations to do incremental, evolutionary improvement. It is a transition method that understands people and the various factors that cause people to disengage. It is a transition method that provides high-level guidance for the creation or adoption of specific practices in a situation where a  problem has been identified. It is a transition methodology that sees no end to the improvement cycle and as such, does not provide guidance on concrete tactics or the order in which you adopt concrete practices.

And because of the opportunistic nature of the culture created by a Kanban Method implementation, all the specific practices that are described by Scrum, SAFe, XP or RUP for that matter, are viable improvement options to specific problems that you may encounter on your journey of continuous improvement.

So get in your vehicle, start improving and go until you hit the horizon!

The Kanban Method – Change Catalyst with No Changes Planned

April 7, 2013 1:37 pm / 2 Comments on The Kanban Method – Change Catalyst with No Changes Planned

I was recently delivering some Kanban training at Yahoo! to a great group of people who were all struggling with many of the same problems we all deal with. Overburdening, long lead times for features and quality challenges, all of which exacerbate each other! Almost all of these people described having been on previous process improvement initiatives. Actually, in some cases, they described being in a non-stop process change initiative. And almost all of them were fatigued by all of the process change initiatives and were very weary of this new “Kanban Method” thing that they were doing.

This seems to be a very common problem that I experience. None of the prescriptive methodologies are solving the underlying problems, organizations are jumping from one prescriptive approach to another and employees are getting tired of it.

The fact that the Kanban Method really isn’t like this is one of the things that has drawn me to it. Let’s revisit the first of the 4 Kanban Method values.

Start with what you do now

Straight from Wikipedia – The Kanban method does not prescribe a specific set of roles or process steps. There is no such thing as the Kanban software development process or the Kanban project management method. The Kanban method starts with the roles and processes you have and stimulates continuous, incremental and evolutionary changes to your system.

This is a central tenant of any LKU Kanban professionals approach to teaching or coaching an organization with The Kanban Method. How can you suggest changes if you don’t know what the problems are? How can you expect a change to succeed without understanding the capabilities of the people within the organization?

When the people are Yahoo! were presented with this first value, they were able to almost immediately relax. We started to hear things like

You mean we don’t have do do anything different?

We can use some of these concepts and ideas within our current process.

Both of which are absolutely true and it is important that people understand this when it comes to starting a Kanban Method implementation.

We then present people with the remainder of the values, which are:

Agree to pursue incremental, evolutionary change
The organization (or team) must agree that continuous, incremental and evolutionary change is the way to make system improvements and make them stick. Sweeping changes may seem more effective but more often than not fail due to resistance and fear in the organization. The Kanban Method encourages continuous small incremental and evolutionary changes to your current system.
Respect the current process, roles, responsibilities & titles
It is likely that the organization currently has some elements that work acceptably and are worth preserving. We must also seek to drive out fear in order to facilitate future change. By agreeing to respect current roles, responsibilities and job titles we eliminate initial fears. This should enable us to gain broader support for our Kanban Method initiative. Perhaps presenting the Kanban Method against an alternative more sweeping approach that would lead to changes in titles, roles, responsibilities and perhaps the wholesale removal of certain positions will help individuals to realize the benefits.
Leadership at all levels
Acts of leadership at all levels in the organization from individual contributors to senior management should be encouraged.

All of which suggest that we do nothing but create an environment that will be supportive of the people who will be finding opportunities to change their processes. That’s it! You’ve now started a Kanban Method implementation, which has often been described as an intent more than a prescriptive, concrete set of things that you have to do.

At Yahoo!, after we had presented everyone with a new approach to thinking about how to approach their problems, we did start to give them some high-level tactics which they could apply when they were ready.

Over the course of the next couple days, we then showed them examples of how they could get more information about how they worked (Core Practices in the Kanban Method). And at no time did we tell them that they had to do any of them, but we described the benefits and limitations of these tactics and by the end of the 2 days of training, most everyone had discovered something valuable and told us they’d be trying to use some of these things in their teams right away. We didn’t know which of the tactics that these people would be trying, but we were encouraged that they felt empowered to start trying to use them at their own pace.

Final Thoughts

In a landscape of teams and organizations getting tired of process change initiatives, it was very rewarding and encouraging to find a group that when presented with The Kanban Method, were excited at the new way of thinking and that they weren’t going to be forced to do something. They were very excited that they would discover what their problems really were and then they would plan out their own changes to the process.

ALM Adoption Success Story – Success Factor 3 – Co-location

March 24, 2013 10:51 pm / Leave a comment

I don’t think I can fully communicate the value of co-location.

Any time I have been asked to help a company in recent years, the engagements have started out with an assessment. I don’t believe that I can provide sound advice unless I understand what the problems are and what the organization’s capabilities are.

One problem that EVERYONE has had so far is the absence of an effective place for their teams to work. Software development is a highly creative endeavor that requires (usually) a significant amount of collaboration between teammates and it constantly surprises me how organizations build terrible places for teams to try and achieve this!

When we started out with the client whom all of these Success Factor posts are about, the development team was spread out across ½ of a floor in an office tower and there were 2 members in a different city. Check out my hand-scribbled floor map with the initial, planned layout of the team members.

clip_image002

This is actually not bad compared to many companies I have observed, but this is far from optimal. The deficiencies that aren’t obvious from this floor map include:

  1. No team-specific collaboration space. Had to book meeting rooms and hope one was available.
  2. The Devs and PM have no whiteboard space. They are in cubicles.
  3. The BA, TW (Technical Writer) and CSM (ScrumMaster) were packed into a large office with minimal whiteboard space.
  4. PO (Product Owner) and HW (Hardware guy) were alone in their offices.
  5. There was no place to have daily stand-up meetings or to have our card wall up where everyone could see it.
  6. The sponsor was on the opposite side of the building.

For a team that is intending to collaborate frequently and intensely, this is a very poor setup. Our sponsor was spending in excess of $100k/month on the team in that room and he wanted to make sure we had every advantage to maximize that cost. So before we even kicked off the project, we made a rather bold request to have a board room near the sponsor converted into a team room. And our request was granted!! The facilities people were a little scared that we’d damage the boardroom table that was in there, so they had that taken out quickly, but the resulting floor plan looked like this:

clip_image004

Now we were excited! We had a room that could hold everyone. There was room for everyone but the PM and HW guy, due to the nature of their roles, didn’t need to participate as intensely as the rest of us, so they maintained their offices. And since our PO was also maintaining some business workload, she maintained her office as well. But all three team members attended all the meetings that we had in the team room and would often drop in to see how things were going. Let’s take a look at the team room.

clip_image006

I have to say, this is the best team room I’ve ever had the pleasure of working in. We had wall-to-wall whiteboards on the West and South walls, and the North and East walls where covered with large PostIt notes. The SE corner of the room had a projector screen and the projector sat on the SE corner of the team table. The computer on the East wall ran Skype and TeamPulse, the Agile Project Management Tool that we used  on a daily basis (from Telerik). The room had a Skype account that was always logged in and you could call up that account and it would always auto-answer with video and put the caller on the projector. There were two microphones in the middle of the big table that would allow everyone to talk from where they were sitting with whomever called in.

I can’t say enough about the sheer wall space in this room. It was fantastic. On the wall-to-wall whiteboards, we had everything from architectural diagrams, to class diagrams, server layouts to retrospective results. We had everything on those whiteboards and they would be able to stay up for as long as needed for the team. We would write our retrospective notes up there, and leave them for the entire next sprint. Then the that sprint’s retrospective notes we be put up, and compared, and discussed. Then the former sprint’s notes would be erased. We had a constant rolling reminder of how important continuous improvement was to us.

WP_002284

 

The PostIt notes were used to keep less volatile things like our value statements right up in front of  us. Also, team policies like our Definitions of Done, or our Prioritization logic where up there for everyone to see. There was never any doubt about how we wanted to work when you were in the team room.

WP_002277

We were creating a mobile system that included on-board tablets in trucks and we had our QA station right there behind our QA professional team mate, our PO and our BA! They could check specs, and then turn around and try it out right there in the QA environment. And if there was ever a problem, the developers could (and usually would) hear about it right away. That was one great aspect of our room that allowed our quality process become pervasive of everything that we did in that room.

WP_002279

I can tell you about a time that our QA lead was working on a test script in Microsoft Test Manager. Then he turned and tried the test step on the tablet and discovered a bug for a feature that was in the iteration. He called the developer over, who saw the defect right away. The QA lead logged the bug and the developer, whom had luckily just finished up a task, was able to pick up the bug and fix it right away. Our QA process was such that we could fix a bug, submit the code, all the automated quality checking mechanisms would run and then we could push the passed build up to the QA tablet where the bug had been fixed. In this particular case, the whole process took less than 1 hr. Discovered, Logged, Fixed, Built, Deployed, Re-tested, Passed. It is very rare for me to see a team perform this well.

But I totally believe that a big contributor is the team room that we’ve built for this team. Every team member feels the others pain when something doesn’t go right. This causes us to behave differently. Less selfishly and with a much more holistic approach to building the software solution.

WP_002278

And that was a known feature. The benefits of having the Product Owner, Business Analyst and Sponsor all within 20 feet of the developers is unbelievable. When anyone has a question about a feature or an idea that we’re trying to make real, the entire stack of business-focused people are right there, immediately available to answer the question. The only time that this team ever builds the wrong thing is when we are building something for someone who isn’t in the room. And you can bet that we escalate that immediately to our sponsor. Because he is 15 feet away. Open-mouthed smile

And he just drops in all the time!! If he has a problem, he tells us. If he is curious how we are doing, it pokes his head in. He will see us working on a problem with our process and lend a hand if he can.  And you can bet that this closeness has made the team much more aware of his concerns and challenges. It never feels like Big Brother is watching because there is so much transparency on the team that it is always about trust and helping to get the job done.

I could probably go on and on about all the benefits of this team room but I’ll wrap it up for the moment and leave the rest to your imagination so that you can think about what the benefits of this team room would do for your team.

ALM Adoption Success Story – Success Factor 2 – Visualize Your Work

December 31, 2012 1:04 pm / Leave a comment

Humans love pictures.

We have numerous sayings in our cultures about how powerful visualizations are.

“A picture is worth a thousand words“

“The drawing shows me at one glance what might be spread over ten pages in a book.”

“Every picture tells a story.”

One that the challenges with knowledge work is that for the most part, most of our work is invisible until it’s done. Only Neo can see bits and bytes which leaves the rest of us a little in the dark. If you’re building a building, or digging a hole in the ground, progress is obvious! For invisible work, progress is very difficult to monitor.

So we track work in some software system, but then we hide all of our knowledge in text and numbers! Our love of spreadsheets is epic in proportion. Status reports! MS Project files! All of this data!! For all intents and purposes, our work is still invisible! We often mistake this data for knowledge and understanding and the true insights are left hidden in the numbers.

On our project, we knew it would be very important to understand at a glance where we were in our workflow.  We were doing something very novel for this organization and in order to mitigate the risk of heading too far in the wrong direction (which could be any direction at this point), we needed knowledge. We needed to quickly identify roadblocks to progress, which often included self-inflicted delays. We needed to engage with our sponsor in a meaningful manner.

So we started drawing pictures!

The most important “picture” that we have used has been our storyboard. This board is very important to us. It is a muster point for our daily stand-up meetings. It is a place on which to hang “adornments” that help us quickly assess our current state. It is a tool that promotes conversations. And it is always there, silently reminding us to be disciplined with efforts to visualize our work.

teampulse_storyboard

Our storyboard looks like pretty much like any other Agile teams storyboard in form, but this one is a unique work of art. Well, unique in that it is exactly what we need it to be at the moment. It represents our workflow. We have our WIP limits on it. And because we are fairly disciplined in maintaining the current state of all our work, it’s always up to date.

We also visualize our tasks and review these daily as well. TeamPulse has a story board as well as a task board for more granular visualizations.

teampulse_taskboard

teampulse_taskboard_2

We don’t have WIP limits enabled on the tasks boards, but again, the intent is to see work flowing through the system. And with an explicit policy that tasks should have a cycle time of 1 day, any time an item is discussed at 2 stand-up meetings, the team knows that the work isn’t progressing as expected and some sort of investigation and corrective action may need to take place.

Finally, we use TeamPulse dashboards to visualize our progress over the course of an iteration.

teampulse_dashboard

Everyday, we review the storyboards and the tasks boards during our stand-up, and then we review the dashboards to bring the entire conversation back to our progress versus our (the team’s) expectations for the iteration. These dashboards provide that high-level perspective that ties everything back together.

And all of this information is available on the web, to everyone on the project team, including the sponsor. There is no need to interpret numbers. There isn’t a report that needs to be compiled. And the information we want to present is immediately available in a very easy to consume and impactful format because a picture is worth a thousand words!

Going back to the first ALM Adoption Success Factor of Transparency, having something to be transparent with has been a key enabler of success for our team as we strive to deliver this project and continuously improve and get better as we do it.

Series List

  1. Success Factor 1 – Transparency
  2. Success Factor 2 – Visualize Your Work
  3. Coming soon – Success Factor 3 – Co-location
  4. Coming soon – Success Factor 4 – Invest In Your Tools
  5. Coming soon – Success Factor 5 – Retrospectives

ALM Adoption Success Story – Success Factor 1 – Transparency

November 10, 2012 10:01 pm / Leave a comment

This is a story about my job, which I love.

During the day, I’m a mild-mannered process consultant (read: Lean/Agile evangelist) for Imaginet, a technology consulting firm that provides end-to-end software development services primarily specializing in Microsoft products and technologies. The really cool thing about Imaginet is that we are large enough to be able to help companies with projects that span the full lifecycle of solutions development, or Application Lifecycle Management as it is more well known. And these projects often involve helping organizations adopt, refine or improve their existing ALM processes.

That is the part that I get excited about. As a process consultant and change agent, I get to help companies take their development processes to the next level and build an organizational culture that is capable of continuing that growth.

It was in this context that our current client engaged us. They were going to build a team that was expected to build a mobile transportation solution that would help them manage a fleet of trucks. This client had never had a core competency in software development but realized that in order to realize their vision, they would need to become competent as there was no off-the-shelf solution that would fit their needs. They did have experience with traditionally managed knowledge work projects and really felt that this was not going to lead to a successful project. There were far too many unknowns and risks and they knew they would need to learn and adapt very quickly throughout the project.

So we all decided to adopt an Agile/Lean mindset and build a process that would help us deliver in this challenging situation.

This long preamble is really just setting the stage for me to share with you what I think were the 5 core principles that we used on this project to ensure that the mindset and methodology development worked and became institutionalized. I’m hoping that by showing you how they affected the way that we work and the benefits, you’ll be able to learn from us and see if they could work for you. This 5-part series won’t be as much about the methodology we ended up with as much as it is about how we ensured that the right methodology for the organization and project emerged and that we maximized our chances of success.

Success Factor 1 – Transparency

The first core principle that we followed was to provide as much transparency into everything that we did, the information that we had and the challenges that we faced. We were so focused on this transparency that it actually tended to border on continuous broadcasting.

In an environment where there is a lot of uncertainty and risk, we felt that it was crucial to our success that we get as much information as possible from as many sources as possible and to engage anyone who could help us succeed. And with a project sponsor who was taking a significant risk in building a new competency for his organization, it was important that he see how we were working, the challenges we faced, and that we were always looking to improve the way that we worked.

To that end, we used numerous tactics to provide as much information on how we were working at a glance to anyone who was interested. These tactics included:

  • a big team room which encouraged information sharing and broadcasting
  • digital storyboard (work management system) that was projected onto a screen at all times and accessible anytime from a browser
  • daily stand-up meetings where anyone was invited to attend
  • iteration planning and retrospective meetings every 2 weeks, anyone could attend and the outcomes of these meetings were left in plain sight for anyone to see
  • team Skype account that would auto-answer (silently I might add) and project onto the screen, with a live video feed and multiple microphones in the room
  • Skype accounts and webcams for all team members
  • tons of whiteboards and large post-it notes that we write on continuously – every wall in the room (600+ sq. ft room) was covered in information and updated frequently
  • large post-it notes on the wall outside the team room to notify anyone walking past in the hall
  • email notification of significant events in the development process (e.g. broken builds, server outages)

 

WP_002280WP_002277WP_002281WP_002284

And it is working!

Our sponsor, who sits across the hall, frequently comes into the room and sees exactly what the team is doing. Our openness has fostered a culture of trust between him and the team that allows both to ask questions, provide inputs, and make decisions for the good of the project together. And one of the really cool aspects of his interactions with us is that he very rarely comes in and asks us how we are doing or where the project is at. He already knows! He usually comes in asking about a specific item we are working on, or asking if he can help with one of our problems.

We never have to defend our methodology because we are constantly sharing it with everyone and allowing them to participate in its improvement. This is one of the hard parts of an Agile adoption project that is easily avoided by aggressively being transparent.

Another benefit of this level of openness is that when we have brought on a new team member, which has happened several times, they are immediately immersed in a LOT of project information. This ranges from work in progress, upcoming stories, improvement work items from the retrospective and any risks or challenges that we are actively facing. We also have numerous big PostIt notes that contain the values and principles that we have chosen to follow as we evolve our methodology. How we perceive value, prioritize and the core vision for the product is all up on the walls all the time.

We have received help from a variety of people within the organization who saw something that we had on our boards that they could help with. These helpful acts ranged from sharing critical bits of information that helped us make a much better decision to actually removing a roadblock or impediment from our current blockages. And without this level of transparency, there is a good chance that these helpful acts would have been delayed if they had even arrived at all.

Transparency has been, and will continue to be, a significant cultural aspect of our team that we feel helps drive our success.

Do you have any transparency tactics you’d like to share? Please do! Comments and thoughts are always encouraged!

Cheers.
Dave

p.s. I plan to enhance this post with pictures soon, but I’m under a deadline to get this out (thanks Dylan) so they’ll have to wait! Please check back in the next couple days.

p.p.s. This blog is being inspired by a competition between a bunch of us to see who fails the blogging frequency requirement first! Please check out the blogs of all these other awesome guys and encourage them to keep on blogging too!

Series List

  1. Success Factor 1 – Transparency
  2. Success Factor 2 – Visualize Your Work
  3. Coming soon – Success Factor 3 – Co-location
  4. Coming soon – Success Factor 4 – Invest In Your Tools
  5. Coming soon – Success Factor 5 – Retrospectives