00068a7What do you get when you assemble 1,000+ software developers from 100+ universities for 36 hours at the Big House at the University of Michigan?  mHacks – the most epic hackathon in the country!  mHacks took place September 20-22 and there were only two rules: hackers had to start with a new idea or project and they had to demonstrate the product or application at the end of the 36 hour competition. For many folks, hacking may have a negative connotation, but for hackers that take part in hack-a-thons (hacking marathons), it’s all about the collaborative effort of developing valuable pieces of software in short time frames.  If you think this sounds familiar, it’s because it mirrors many of the goals of what Pillar calls Speed-to-Value.  The premise behind Speed-to-Value combines value-based prioritization, releasing thin slices, and advanced software engineering techniques. The results of using this method are: reducing the cost of change and software  released to market in quicker intervals – often months or weeks.  This fast feedback loop allows companies to capitalize their software investment earlier as well as receive early market feedback that serves as validated learning for future releases of their products.

Screen Shot 2013-10-14 at 9.12.36 AM

Pillar had the opportunity to sponsor this year’s hack-a-thon and provide not only financial support, but also software engineering consulting.  We had a total of 6 consultants that spent varying amounts of time with the hackers throughout the weekend.  From helping teams understand the “Value Story” (high-level outcomes quantified in terms of business value), to creating plans and strategies to map out and complete their work, and providing support and encouragement, Pillar was eager to work with students to help them with their hacks.  At the end of the competition, development teams had an opportunity to make a pitch for their hack to the hack-a-thon organizers as well as sponsors that set challenges and awards in specific categories like most efficient or most technically impressive.

Speed@ValueGraphicProposalVersion2The grand prize winner was a recycling bin sorter that used Fast Fourier Transforms to match the sound waves of the clinging or thudding of various metals and plastics against a wooden trap door.  Certain sound waves that matched those of recyclable materials caused the trap door to open to the left, depositing contents in a recyclable container.  Every other sound caused the trap door to open to the right and deposit contents in the trash. The team not only developed the hardware and software, but also pitched the idea, or value story, behind their hack.  During their initial pitch, the team realized that the ambient music being fed in through the PA system was distorting the sound waves.   They were able to quickly tune and adjust their system to account for their environment and by the second time the judges passed through, the system worked as advertised. These hackers effectively found ways to reduce the cost of change and make quick adjustments on the fly. 

This just goes to show, that even at mHacks, Speed to Value appears to be the winning formula.

 JD Sallee | VP | Pillar

If you’re a marketing executive, IT Executive or CEO, I think you would agree, traditional marketing is soon becoming a thing of the past.  Today’s consumer is harder to reach, but if you connect with them they are more loyal than ever.

For those of you that are IT centric, responsive design is not the answer.  The basic premise is flawed.  A designed response is the right approach:  market to what is important to your customer, rather than just pitching your product.    To properly execute a marketing strategy today, you must re-think what’s important and stick to your target customer. Your marketing reach may be an extension of a current service or that of providing a service completely outside your core offering.  For example, has anybody ever used a little app called MobileDay? It’s very simple; it dials into conference calls and automatically keys your passcode.   Why didn’t a long distance carrier or a switch provider develop this?  This is the “out of the box” thinking marketing must have.  Instead who built it?  Some savvy tech guy that said, “Hey this is an easy problem to solve.”

There are loads of surprising opportunities that are still untapped by many main stay organizations.  Smart shopping services for grocers, tighter integration to social media, self-portraits that trigger shoppers “where” to find specific fashion items.    YouTube is loaded with self-made fashion and make-up experts; why can’t their video content direct the consumer where to purchase those items?    How about location based auto, boat and motorcycle guides for those in a definite product funnel?

Two things need to happen in my opinion in most large organizations.   Marketing and IT need to forge a new relationship based upon speed, agility and best to market strategies.  The days are over in IT of “wait your turn”, or “get in line until we get to you”.    New methods, new techniques and new approaches to marketing must be employed jointly.  Out-of-the-box marketers sitting right next to savvy tech guys, understanding and mining service opportunities for their target customer.  Test first marketing methods, fail fast and learn fast strategies are just a few.

If internal IT can’t keep up, CEO’s first talk to the CIO.  If they can’t comply, you must allow Marketing to go outside the company to find a partner, and it’s not a traditional Marketing Services company; it  must be a hybrid,  with new, fresh, progressive marketing techniques,  i.e. viral growth hacking methods – and this must be combined with superior technical acumen.  The combination will result in amazing results.  Solutions must be simple, but deliver super high value.

For more information watch this video.

Bob Myers | CEO | Pillar

There are many approaches to consulting and transformation services. In today’s post, I would like to highlight a difference between Pillar’s model and other consultancies that special in “Agile coaching” services.

At Pillar, we say that “Execution is Everything.” (It’s our tagline.)  We feel like a consultant needs to be in the trenches with our clients rather than offering advice as an onlooker. We fall firmly on the side of a consultant who is part of the team, contributing velocity, and offering advice as part of that role.

Two major factors that contribute to our viewpoint are a) credibility with teams, and b) staying relevant.

If an Agile coach is offering advice to a team without actually taking on work themselves, they often have great difficulty establishing credibility with the teams they are directing. The coach doesn’t have a strong basis to answer objections when teams say “We’re different because…”

Secondly, people who spend months or even years doing nothing but coaching tend to fall out of step with what really works versus what seems like it would work in the mind of the coach.

As far as I know, the concept of an “Agile coach” originated from the “life coaching” trend of the past decade. Unfortunately, the limited benefits customers have experienced with hiring a life coach carry over to the Agile coaching world.

But the consultant who is a part of the day-to-day work is a different story. At Pillar, we feel that our consultants learn the customer’s environment and constraints (real or imagined) by doing the work, by walking a mile in our client’s moccasins.

Analogies are dangerous, but I’m going to try one here. If the Agile coaching industry mirrors life coaching, then Pillar’s approach mirrors a teaching hospital. There are two views of a teaching hospital. One is that this is a place where people learn how to be doctors and nurses. But a teaching hospital is also the best hospital to get your operation. That’s because you have the top doctors teaching the medical students, but those same top doctors are also doing surgeries. They don’t just work in a classroom; the whole hospital is their classroom.

You’ll find that Pillar doesn’t put heavy emphasis on training classes. Our classes are short and cheap. We don’t do Agile coaching. We work more like a teaching hospital. We want our best people involved in projects up to their elbows. We don’t want coaches. Because we think coaching is a lot less effective than experts doing the work beside the people learning.

It’s a difference in philosophy. And it is the foundation of why we say “Execution is Everything.”

 Daryl Kulak | VP, Ohio Valley | Pillar

A month or so back, Charlie Snider* and I had the pleasure of teaching a session of Pillar’s “Day in the Life of Agile”** class to a really cool non-profit organization called Michigan Suburbs Alliance***.  Although they have little in common with our usual clients in the software industry, as the day to day work goes, there have other aspects in common that almost all organizations share. Things like well managed projects, self-sustaining teams, and the desire to have delighted employees and customers. 

 

We knew there were going to be a couple challenges right off the bat. The first was that our standard presentation was full of terms and examples directly related to the software industry, such as Test Driven Development and Continuous Integration (CI). The second was that we usually have the participants focus on a sample software project built with Scratch (http://scratch.mit.edu/) and we knew this crowd would have little ability to relate that kind of work to their daily routines.

So instead we drove the focus of the class toward the broader practices of Agile, like Value Stories, User Stories, Story Mapping, Collaboration, Continuous Learning, Failing Fast and Retrospectives. Based off of participant interaction and feedback, this worked very well and seemed to provide great value to them. However, when it came to the example project we had them focus on, it may not have been the best choice. My thinking before hand was to establish a context that the group may be familiar with so that they could focus on learning the practices without worrying about the example itself.

 

I thought it made perfect sense that a group of individuals who deal with suburbs and communities all the time should focus on building a “paper city.” (Note – I think it was eventually at one point named”Danopolis” by one of the teams which I completely support). Unfortunately, not for the first time, and certainly not the last, I was not entirely correct in my thinking. Although it related well to their world, it was also very hard for them to break ties to the realities they face everyday with city planning. They had some trouble abstracting themselves and focusing on practices like we had hoped.

 

Overall, I think the day was a great success. I know that Charlie and I walked away with some great learning and as far as I can tell the folks from MSA did as well. To get a glance at the day from the MSA perspective please check out their related post here http://www.michigansuburbsalliance.org/2013/06/03/its-an-agile-world-for-nonprofits/.

 

Looking forward to the next chance we get to explore Agile Beyond Software.

 

d2.

 

* Fellow pillar consultant (aka. awesome guy) almost as interested in Agile beyond the dev floor as I am.

 

** A day-long session of real world, hands on learning, focused on the principles and practices Agile. Usually held once a month at both our Ann Arbor and Columbus Forge locations. More info on those here http://pillartechnology.com/connect/events/

*** Michigan Suburbs Alliance is 501(c)(3) nonprofit organization based out of Ferndale and Ypsilanti. Founded in 2002 to address the shared challenges of metro Detroit’s inner ring suburbs, they have grown to engage more than 31 communities representing more than a million residents. They work with cities and partners across a variety of issue areas, always bringing a regional perspective, unique solutions and a collaborative spirit. Read more about them here http://www.michigansuburbsalliance.org/

 Daniel Davis | Delivery Lead | Pillar

For years now the IT industry has been discussing Agile and the use of various tools to elicit, make visible the work in progress, and then rapidly deliver business value.  These methods have proven to be great tools for IT and have yielded significantly faster and higher quality business solutions if employed properly.  In many cases we have seen astoundingly improved time to market and quality, as identified in last month’s newsletter about QSM Agile performance data.  Pillar recently introduced a next generation tool designed specifically for the business that wants to take the next step in business agility.  This tool rapidly identifies and discovers new business opportunities and allows them flow seamlessly into a high performance agile team.  It is the next step towards our quest of completing the business agility saga.

Available for download is the new Pillar Business Agility Wall. (click here)

 By clicking the link below you will be able to download a PDF of four new tools in the business agility toolkit.  In this section there is also an instructional video of how to use the tool.  This tool is free for all subscribers.

In summary the Business Agility Wall solves four essential problems in high performance organizations:

1. It is an extremely rapid way to get the heart of the business strategy.

2. It makes each strategic action and its impact on your client, your people, and your organization big and visible, while allowing you to insure a healthy balance.

3. Its makes the urgent, important decisions obvious.

4. It provides an extremely fast tool for managing investment vs. spend and is an easier and faster way to visualize strategic impacts.

We hope you will try this new tool and you find it beneficial for your organization.  For an in person demonstration please contact us at salesteam@pillartechnology.com

 
Bob Myers | CEO | Pillar

Motivated by Freedom

I just attended the Management 3.0 class taught by Jurgen Appelo at the Forge on Feb. 26th & 27th. It was a great class! Jurgen is a very engaging speaker with lots of anecdotes and stories from his years of management experience – especially his experience leading agile teams. His book is called Management 3.0 because he said he had to put a version number on it to get software developers to take it seriously. :) He said Management 1.0 is the old style command and control and that Management 2.0 is more the manager as coach model. Management 3.0 is the art of empowering the teams and adopting a servant leadership approach to leading teams. The class was very experiential with lots of hands on exercises and small group work. I really appreciated the opportunity for networking and for gai

ning insight into the challenges that leaders at different organizations are facing in their transition to managing agile teams.

 The one exercise which I plan to put into practice right away was called Moving Motivators. He gave us this cool deck of 10 cards each of which represents a different kind of motivating factor.For example, am I more motivated by Freedom than by Mastery? You start out by asking someone to place the 10 cards in order of importance in terms of how much each factor affects their motivation at work. This is a great way to get a better understanding of what motivates the people on your team. Then you can explore how a change will affect each factor. For example, if my company decides to adopt Scrum – my Mastery may be affected positively but my Freedom may go down. I am eager to try this with my teams!

Linda Farrenkopf | Director Ohio Valley Region | Pillar

Last Saturday I had the honor of speaking at Prizcon 2013; a very unique event sponsored by Pillar and the Win Win Institute for Response-Able Reentry.  You probably haven’t heard of this conference and there is a good reason why…It is for prisoners at the Marion Correctional Institute.

 I must say I was a little out of my comfort zone, and not simply due to the fact that I was in a prison, surrounded by prisoners. As the Keynote Speaker, I was surrounded by my own set of seemingly impossible questions: what insight could I possibly offer; what has their life taught them; what do they know; will they, can they glean any benefit from what I have to say? The last thing I wanted to do was to create false hope, and yet, for many of them, their best opportunity is to foster a career in technology.

 As I looked across the crowd, looked into these men’s eyes, I saw excitement and hope. In some I saw a real willingness to change, to be better, to start anew. With this, the seemingly impossible question surrounding us struck a chord: upon re-entry, can a man really have a life?

 I am reminded of a highly qualified individual that Pillar was introduced to through Dan Wiebe. This man was an ex-con with skills in software development and communication. All indications led us to believe he was a changed man. Before we could even begin to consider giving him a shot at development, the system got in the way. The red tape of insurance liability, background checks and the like foiled the possibility. There must be a better way!

When a prisoner is released, hasn’t he done his time? Does the system support real forgiveness and real restoration? Is it possible to make amends, pay one’s dues, and get on with a productive and fruitful life?

We’ve all heard the sentiments, ‘they’ll be back’, ‘repeat offenders’, ‘lifers!’ But is the current system pre-determining this? Men leave prison and struggle unsuccessfully to find meaningful work; the weight of the world crashes down on them; they lose hope and with it, their desire; they are forced to resort to the same bad behavior… There must be a better way! With all of our scientific and technological capabilities is there no way to make re-entry into a real career possible?

 My thanks to Dan Wiebe for opening my eyes to the reality of the uphill battle these men face. At Pillar we never think things are impossible, just really hard.  I hope you will join me in this really hard task: let’s allow these men to really be changed men and offer positive answers to these seemingly “impossible” questions. 

Bob Myers | CEO | Pillar

With our recent introduction of the Forge, I have been thinking a lot about how to facilitate rapid transformation in our people and in our community. As a company we teach people new behaviors to facilitate greater efficiency in delivering business value through superior software execution (speed to value, agile). But as I think about change, I am more and more inclined that greater time and emphasis needs to be spent on how to change the way people think, a la the Forge.

“If you change the way you think, you will change the way you behave.” Our quest is to create a system, an environment, a method for effectively and rapidly changing the way we and others think. If we can accomplish this mission the possibilities and velocity of change will be boundless, maybe even brilliant.

Over the next several months, I will be spending a large portion of my time and effort, thinking about how to change our thinking. My first stab at this is a new workshop I have completed called “Activating your Right Brain in a left brain world“. In this workshop I will help people discover the power of the right brain (creative), when they are using it and some of the limitations (constraints) that hold us back in our left brain, logical cognition. I’m anxious to explore this with others and see if we can better solve complex business problems with more right brain activity.

 

Bob Myers | CEO | Pillar

This is another excerpt from my upcoming book “Agile in the Bloodstream: Creating Change-Ready Teams Using the Power of Systems Thinking.” It was also the basis of my talk at Agile 2009. I hope you enjoy it.

Although I’m an Agile coach by trade, I’m really a storyteller. In this article, I’d like to tell you five stories, mostly based on real life that might help you see how Agile can become mechanical. I have changed the names to something ridiculous to make sure I don’t implicate anyone.

Agile Expert Syndrome

Once upon a time, in a company called Neverland Insurance, there was a team and an Agile consultant. Together, they decided to try to build an application. The team was about ten people, and the Agile consultant had a really, really good reputation as a brilliant person and dedicated Agilist. The team felt lucky to have him. The Agile consultant’s name was Sticky LaGrange.

Sticky helped the team get started and taught them all the Agile practices. The team carefully followed Sticky’s words and asked him questions whenever they weren’t exactly sure what to do. Sticky was very helpful and patient. Not only that, but Sticky prided himself on writing more code than any other team member, even though he was spending so much time coaching people. Sticky was truly amazing.

At the end, the application was finished on-time and within budget. Everyone at Neverland was so impressed. The team was so proud.

Then the wicked king of Neverland cut budgets and the team had to say goodbye to Sticky. Surely they could they succeed without Sticky, he had taught them so well. So the team went on to another application and began work. They tried to remember everything that Sticky had told them. If in doubt, someone in the team room would inevitably ask “What would Sticky do?” The group would try to remember what Sticky would have done and then replicated it faithfully.

But things were falling apart. Different team members remembered Sticky’s advice differently. And sometimes, inexplicably, Sticky’s advice seemed to be wrong! When applied in this new situation, Sticky’s advice broke down. How could Sticky be wrong?

Some team members said that maybe they should go beyond Sticky’s advice. But other people thought this was a terrible idea. “That’s not True Agile!” they cried. Why deviate from Sticky’s advice if it had worked so well the first time?
Unfortunately, the team at Neverland had fallen into what I call the Agile Expert Syndrome. This is when people feel like they have to follow the advice of an expert, either in the form of a consultant or a book or an article.

Whenever a team gets into this compliance mode, they are in trouble. They are performing Agile mechanically. And teams that are doing Mechanical Agile always get into trouble, because they will always hit a snag that falls in between the advice they received from the Expert. And as soon as that happens, they will get into a rut where they are trying to guess what the Expert would do, instead of applying their own intelligence and doing the best thing they can think to do.

Separation of Decision-Making and the Work

Once upon a time there was a clothing manufacturing company called Cheap Green Shirts.com. The company had several Agile teams that were doing a great job and were highly productive. Their velocity was high, the teams were happy and the business was benefiting.

“I think we can juice these teams up even more,” said one of the vice-presidents. “I’ve noticed that Team A is doing significantly better than the other teams, so we should take the best practices from Team A and give them to the other teams. That way, we’ll have all teams performing at the level of Team A. It will be great!”

So the vice-president set up a group of Agile experts that he called a Software Engineering Process Group (SEPG) that was able to advice the teams. The SEPG (pronounced seepage) experts carefully examined each practice used by each team, harvested them and chose the best of the best, then gave them back to the teams.

Surprisingly, the teams didn’t use many of the new practices. The SEPG experts were incensed. “These teams don’t want to learn,” the SEPG experts groaned. “The SEPG dudes don’t understand our work,” said the teams.

So the vice-president mandated that the groups use what the SEPG experts had come up with. The groups dutifully used the new practices. At this point, velocity dropped for each and every group. How could this happen? The SEPG experts explained “The teams are doing the practices wrong!” The teams replied “These practices don’t work for us.”

The vice-president fell into a mechanical Agile problem that we call “separation of decision-making and the work.” The further the decision-making happens away from the person doing the work, the worse the result will be. The SEPG group was far removed from the teams, they weren’t familiar with the details of the day-to-day work, and so , even though they were experts, their recommendations failed miserably. At the beginning, the teams were making their own decisions about which practices to use, which ones were best for them. By removing that decision-making from the local team members and giving it to a separate group, the vice-president reduced velocity, team satisfaction and caused problems for everyone. The vice-president was thinking that the teams were machines, not people.

Blame the Person, Not the System

A company had two teams working together. One team was providing a set of requirements for the other team to implement in code. The first team we’ll call the Uppities, because they were upstream in the process. The second team we’ll call the Downers, because they were downstream in the process.

First of all, the Uppities and the Downers were both doing Agile, just different variations. The Uppities were on a longer iteration cycle of 6 weeks, whereas the Downers were using 2 week iterations. But everyone was doing some flavor of Agile.

Still, the Uppities did not get along too well with the Downers. The Uppities tended to have big emergencies and would dump high-priority work into the Downers area, even in mid-iteration. Since the Uppities work was the most important work in the company, the Downers had to comply.

One day, I was in a conversation with someone from the downstream team, the Downers. Let’s call him Donny.
I asked Donny what he thought was the origin of the conflicts between the Uppities and the Downers. “Well, it’s the Uppities, of course!” he said. “They have no respect for other teams! They think they own the place!”
I asked Donny if he could imagine what it was like from the Uppities perspective.

“Oh sure, that’s no problem. I used to work there,” Donny said, to my surprise. “And when I was an Uppity, it was pretty obvious that the Downers were the problem. But now I can see the REAL story, that the Uppities are the entire problem, and not the Downers!”

I couldn’t help wondering if Donny was falling into another aspect of Mechanical Agile, which I call “Blame the Person, not the System.” Donny, no matter which team he belonged to, was thinking that the other team was the problem, instead of thinking that the system was the problem. By system I don’t mean the software application, I mean the methods of interaction between the two teams, even the culture. There were probably problems in the overall system that were causing this conflict, and those systemic problems were being misinterpreted as “the other guy’s fault.”

If we can always take an attitude of “Let’s fix the system together” rather than getting into a blame-game of determining who’s at fault (Hint: it’s always the other guy), we can make much more progress.

Just Tell Me What to Do, Boss

My employer, Pillar Technology, has a very rigorous interview process for developers. Part of our process is that the prospective recruit has to pair with one of our Pillar experts to allow us to evaluate the person’s ability to perform as a test-driven developer.

In one case that I was able to observe from across the team room, a prospective recruit came into the room and sat down with our Pillar expert. We’ll call the prospective recruit Emo. Since this was about test-driven development, the Pillar expert asked Emo to look at some existing code, and an existing unit test, and try to figure out how to make the test pass.

The test was very simple. It provided some input and then asserted that the variable being returned should equal “12.”

Emo looked at the test, then flipped over to the code. After a quick glance at the code, Emo took the cursor and deleted it all. In its place, Emo wrote code that would make the return variable equal to “12.” Then Emo smiled at the Pillar expert.

This was both the shortest pairing interview I have ever seen, and the longest post-interview retrospective.
Emo fell into an aspect of Mechanical Agile that I call “Just Tell Me What to Do, Boss.” If our team members get into a mindset where they just want to take direction from their boss, we’re all in trouble. We need every team member to be applying their full intelligence to every problem. As soon as they get into the mode of following directions, then we get solutions like what Emo did in the interview.

Team members can get into this way of thinking quite easily. Managers who are coercive create team members like this, because people are afraid to do anything different than exactly what the manager specified. But even the presence of detailed documentation on “what you should do” can create these types of team members.

We need to do everything we can to avoid getting our team members into a mindset like poor Emo.

Competition Between People and Teams

A VP at a telecom company had six Agile teams all doing great work. Then he had an idea. He realized he could “kick it up a notch” by getting his teams to compete against each other for a monthly prize.

We’ll call this VP Emeril.

Emeril said he would offer free lunches for a week for the team that could top the other teams in velocity.
The competition began. The teams immediately started looking for ways to game the system. They found that if they made their storypoints smaller, they could deliver more of them without doing extra work. The teams went through a period of “storypoint inflation” for several months until the VP realized what was going on. Finally, he mandated that the storypoints had to be all the same size.

Then the teams realized that quality and defects were not part of the measurement, so they reduced the amount of time they spent on testing in each iteration. Sure enough, the points went up, but so did the defects.

So, the VP eventually jumped in and mandated that defects would be part of the measurement. The more defects found, the lower the team would score.

This sounded okay, but the VP didn’t realize that the testers were also part of the teams. They were also in line for free lunches. So, by making this third decree, the VP was telling the testers “Don’t find too many defects or you won’t get the free lunches.”

And on it went. You can imagine that these competitions didn’t help things much. And the cooperation that naturally was occurring between the teams disappeared. Why help the other team gain velocity at our expense??

The VP was suffering from a symptom of Mechanical Agile called “Competition Between People and Teams.” Put people or teams in competition with each other and you will ensure that they will meet your targets, even if they have to destroy your organization to do it.

Five Symptoms – Five Stories

These are some of the problems that keep your Agile teams from scaling up and sustaining. And they all relate back to treating people like machines instead of like people.

To solve the Mechanical Agile, no amount of new practices or Lean, Kanban or Six Sigma will help you. Scrum of Scrums won’t really help you. More meetings won’t help you. Only addressing the attitude of thinking of people as machines will help you.

Some Ideas That May Help

Here are some suggestions to improve your teams’ ability to scale and sustain. These aren’t meant to be singular solutions to the first five symptoms, you could say that all five of these solutions solve all five symptoms.

If You See a Best Practice By the Side of the Road – Kill It

The idea of “best practices” can become quite mechanical. It can lead directly to Agile Expert Syndrome of any of the problems we’ve discussed above.

I’m not saying that you can never take a practice that you see elsewhere and try it in your situation. I’m saying that you shouldn’t do it blindly.

Blindly following “best practices” always gets us into trouble. We can try to understand practices used elsewhere, but then we can jump into answering “How can that work here? How do we need to change it to fit?”

Close the Gap Between Decision-Making and the Work

As we saw with the SEPG experts, it hurts when we take decision-making away from the person doing the work. The further that gap, the bigger the hurt. We need to move decision-making as close to the work as possible. If the person doing the work can make all decisions about that work, that is optimal. If we have to separate it for some reason, try to keep it as close as possible (within the same team, hopefully).

Break Down the Boundaries Between Teams

A manager’s biggest responsibility is to break down the boundaries between teams. Having teams compete against one another erects boundaries. A manager stating that “Everything must go through me” to communicate to other teams erects boundaries.

The best Agile manager will work to remove boundaries, finding ways the team can have unfettered communication with other teams, groups, departments.

Value the Unstructured

Quite often when we see a problem, we try to invent some structure to fix it. Have two Agile teams that need to communicate more? Set up a Scrum of Scrums meeting.

But there is also value in the unstructured. Sometimes it is worth trying to find a way to solve problems that doesn’t involve more structure, more meetings, more roles, more documents, more setup.
Are there things we can change about our attitude that can improve the situation? If so, what can we do to change our own attitudes? How can we change the culture of the way work is done in our team?

Avoid Over-Engineering Your Processes

We often use the term software engineering to describe how we create software. Software, once created, is certainly mechanical, so thinking of ourselves as building something mechanical can make sense when describing software creation.

However, it can cause trouble when we try to engineer processes. Our processes cannot be mechanical, for all the reasons in my stories above. They have to be living, breathing processes that can adapt effortlessly. The only way to have processes that are alive like this are to have openings in them for people to do what they think is the right thing to do. We need to allow people to act like people, and not try to force them into a machine model that we’ve created for them.

Photo credit – gfpeck on Flickr

 

Daryl Kulak
Chief Sales, Fulfillment Officer

Agile Illth

(Excerpt from the upcoming book “Agile in the Bloodstream” by Daryl Kulak and Dr. Hong Li)

Agile is an exciting prospect. It is usually pretty easy to see that an Agile project is physically different than other ways of developing software (team rooms, pair programming, etc.). Moving to Agile can feel like jumping across a chasm into a whole new territory.

Once you’re there, and it starts working well, Agile can be exhilarating. We’ve seen teams experience true joy from producing results quickly and being so deeply in touch with their customers using Agile.

But often a strange thing happens with Agile teams inside non-Agile organizations. They don’t expand. The Agile team may be able to produce great successes but the rest of the organization doesn’t recognize the team’s victories or, worse, start working against the team to ensure its failure.

Is this crazy? Is the rest of the organization insane with jealousy because the Agile team has found something new and useful? Yes, this is possible. But, in our experience, there is more going on. Introducing Agile into a non-Agile organization creates all kinds of issues that the organization and the Agile team need to address upfront if the team wants to be successful in the long term. We group these issues into a category we callillth.

 

Agile is Like Wal-Mart (Sort Of…A Little)

Illth.Nineteenth century English art critic John Ruskin created this word to describe the messy bits that came along with wealth. In Ruskin’s time, he saw that wealth was being created in various ways in England, with businesses and factories, but with those advances came the “side effects” of wealth, which were not as desirable. Underpaid and overworked laborers’ dismal lives could have been considered illth. The pollution and grime created by the factories in the community would have been illth. And the unrelenting movement of money from the poor to the rich was certainly illth in Ruskin’s mind.

Here is the definition of illth in Ruskin’s own words:

Wealth, therefore, is ‘The possession of the valuable by the valiant’; and in considering it as a power existing in a nation, the two elements, the value of the thing, and the valour of its possessor, must be estimated together. Whence it appears that many of the persons commonly considered wealthy, are in reality no more wealthy than the locks of their own strong boxes, they being inherently and eternally incapable of wealth; and operating for the nation, in an economical point of view, either as pools of dead water, and eddies in a stream (which, so long as the stream flows, are useless, oronly to drown people, but may become of importance in a state of stagnation should the stream dry); or else, as dams in a river, of which the ultimate service depends not on the dam, but the miller; or else, serve as mere accidental stays and impediments, acting not as wealth, but (for we ought to have a correspondent term) as ‘illth,’ causing various devastation and trouble around them in all directions; or lastly, act not at all, but are merely animated conditions of delay, (no use being possible of anything they have until they are dead,) in which last condition they are nevertheless often useful asdelays, and ‘impedimenta.’

Although Ruskin‘s definition sounds overly damning toward the rich, we still feel there are aspects of this definition that can be quite useful.

Since Ruskin’s time, illth has been used only sparingly in books and speech, mostly notably by George Bernard Shaw in his essays on socialism. But it seems like a good word. Certainly, often when we do something good in our community, there are bad things that come with it that we need to deal with. Pollution is the best example in our own time. Our incredible engines of growth in North America, Europe and Asia have generated great wealth for millions of people. But the scourge of pollution has inevitably followed that wealth, darkening its splendor.

Wal-Mart is a great example of wealth and illth. When Wal-Mart comes to town, there are great things that happen. People can get stuff for good prices and there are more jobs, lots more jobs. But there is also illth. Wal-Mart has a tendency to have a bad effect on the local smaller stores, putting them out of business because they can’t compete with the low prices.

What does illth have to do with Agile? Please don’t be offended that we are comparing Agile to Wal-Mart, and please don’t think that we’re saying that Agile team members are very like the idle rich that Ruskin seems to detest so much.

When you look at a highly-functioning Agile team, you can see their success as a form of wealth. An Agile team is often somehow magically able to accomplish mountains more work than a comparable waterfall team, and yet they work fewer hours and are happier with their work. The wealth flows.

So where is the illth? It might not be within the team itself, but it could be leaking into the teams surrounding the Agile team. How does the Program Management Office (PMO) feel about the Agile team? Are they “feeling the wealth” or “feeling the illth?” What is the effect of Agile on the team that deploys applications into production? How about the competency centers? Or the human resources teams?

You don’t have to scratch the surface very hard to find people in a large organization that are actually upset about the Agile team’s successes. Yes, this might sometimes be due to their jealousy of the success, but there is another aspect to it.

Think of your large organization like the body of an animal or a person. What happens when your body ingests something that it doesn’t recognize? White blood cells attack the new thing and try to kill it. War is on, and either the intruder is flushed out of the system or the body dies trying.

Is that necessary in your organization? It doesn’t have to be if you, the Agile team, can manage your illth.

First, let’s examine the problems that an Agile team can create for its neighbors in the large organization. After that section, we’ll look at some solutions that can help Agile and non-Agile co-exist.

Here are some types of Agile illth:

  • Agile vanity
  • Agile project within Non-Agile program
  • Incremental impedance mismatch upstream
  • Incremental impedance mismatch downstream
  • Clash with the corporate methodology
  • Clash with the corporate project management structure and tools
  • Clash with competency centers

Here is a bit about Agile vanity. (We’ll discuss the other topics in a later post.)

Having seen Agile projects in many, many situations and variations, we’ve had the chance to observe a peculiar Agile tendency that we call “Agile vanity.”

In fact, it is quite natural, once you’ve discovered a new and better way of doing something to feel a bit full of yourself for a while. The only trouble is that this can cause great strain in your organization. Let’s look at some of the things that happen when Agile proponents turn into “Agilistas.”

Inside the Agile team, the observation of results helps to create enthusiasm and a willingness to commit time and energy. The team feels like they are being productive and are working well together.

When someone in the team is discussing their project with people outside the team, they may give a sunny picture of what is happening due to their own happiness with their work. The outsider is likely to question these new methods, especially if they haven’t seen it work themselves. This may put the Agile team member on the defensive a bit, feeling like they need to give the most articulate answers or this person might think the Agile team is just being duped by the latest software development “fad.”

Each time this happens, the Agile team members may feel like they just shouldn’t bother interacting with those outside the team, or if they do, maybe they shouldn’t discuss Agile too much for fear of being in a defensive situation again. The other aspect that can arise is that the team members discuss the successes of Agile among themselves but decide that the others “just can’t understand the Agile way.” This creates a barrier between the “insiders” and “outsiders.” This is what we call “Agile vanity.”

The danger here is that, as soon as the team erects this barrier, those outside instantly feel that they need to defend themselves against being viewed as stalwarts of the “old way.” The outsiders begin to come up with lists of reasons why Agile can’t possibly work and why the Agile team’s successes are due to factors other than the Agile practices they are using.

As you can imagine (or possibly as you’ve experienced), this is not productive. The outsiders can be other teams or they can also be the executive managers of the Agile team. The direct and indirect managers of the team can cause a great deal of havoc for the team, at worst hemming them in with random directives that are, subconsciously, being done to ensure the failure of the team.

The same things that help the team stick together can be the very things that distance them from the outside world. And those outsiders are people the Agile team needs to be successful, whether direct managers, co-workers, upstream or downstream projects, or other connecting teams. Agile vanity, although it feels good at the time, can be quite destructive.

It is worth paying equal attention to what is happening “outside the Agile team room” as well as inside. Too many of our Agile practices and principles deal with the goings-on inside the room, but it is what’s happening “out there” that can kill the project too.

Daryl Kulak
Chief Sales, Fulfillment Officer