Skip to content

Feed aggregator

The Agile Coach on Failure

Agile Management Blog - VersionOne - Mon, 03/24/2014 - 18:33

They say the best way to learn is sometimes through failure. I couldn’t agree more.

Now you may be thinking, “Yeah, that sounds nice, but my boss doesn’t like failure. And I don’t like getting called on the carpet. The culture in my company doesn’t encourage risk taking. In fact, we get penalized for failing via negative performance reviews.”

Welcome to the culture of command and control; management by fear.

Now don’t get me wrong. I agree that we should try to mitigate risk. But on the other hand, we might not come up with that new groundbreaking technology if we never take a chance, step outside our comfort zone every now and then.

Funny thing; agile both mitigates and encourages risk at the same time.

It mitigates by employing short, 2-week timeboxes; by allowing the customer to see what we’ve built for them at the end of those timeboxes; by having team retrospectives, identifying what we do well and where we can improve; and by practicing agile technical practices.

An agile culture encourages risk taking by making clear that we will never win in the long-term by sticking to the status quo. We must take calculated risks and invest in them. R&D isn’t the only place that spends money on crazy ideas. The IT divisions are becoming increasingly important to a company’s success or failure.

As an Agile Coach, I find one of the hardest things to learn is to let the team fail. Watching and waiting is not an easy thing to do. That said, as a Coach, I’m not going to allow them to make an epic failure that would cost the company millions of dollars. But I do want the team to feel comfortable taking chances and using failures as an opportunity to learn.

If you’re overly protective of your team’s failures, they will recover from failure more slowly, learn less, and become weaker as a team. And, as you might expect, the opposite holds true.

And an epic failure at the end of a long cycle (6, 9, 12 months) is frowned upon even more, as it should be. Accordingly, this is the dig on the waterfall approach to developing software. At the end of the 12-month project, we may think we got it all right. We may have even worked double-time at the end to get there. But when the day comes to go live, we discover that what we created doesn’t work like it should, isn’t quite what the customer asked for 12 months ago, or the market has changed — and this thing we spent so much time creating is no longer valuable.

It’s not uncommon to end up only using 20% of the original requirements list. That’s a pretty large failure risk, if you ask me. Over my 10 years of managing waterfall projects, I’ve had more than a few projects fail in this way. Of course, as the Project Manager, the fingers were usually pointed at me. I loved my job. NOT!

Enter agile development. I made the transition from Project Manager to ScrumMaster very naturally. For some PMs, it’s not a good fit. Hard to shake that command-and-control mentality. But I liked this new and refreshingly realistic way of working and getting stuff done. If we failed in agile, we failed at the 2-week mark, not at 12 months. Simple. Brilliant. The finger pointing ceased. We succeeded or failed as a team. And if we did fail, we got better the next time, or we pivoted and went a different direction. ‘Why hadn’t we all been doing this the past 4 decades,’ I thought to myself. But that’s another blog topic.

Bill Cosby once said, “The desire to succeed must be greater than the fear of failure.” Ruminate on that.

Is your energy focused on succeeding or failing?

Categories: Companies

Interesting - Packing List for Your Agile Journey Virtual Training

Practical Agility - Dave Rooney - Mon, 03/24/2014 - 18:27
My good friend Gil Broza, author of The Human Side of Agile, pointed me towards an upcoming virtual training event called the Packing List for Your Agile Journey. It's a 5-day event with a tremendous "cast of characters", including Johanna Rothman, Arlo Belshee, Ted Young and Paul Carvalho among others. Gil's approach is to interview each of these 10 industry leaders, having them discuss their
Categories: Blogs

The Real Agility Program – Execution and Delivery Teams

Learn more about our Scrum and Agile training sessions on

In a recent post, Mishkin outlined the Leadership Team component of the Real Agility Program.  While the Leadership Team track focuses on developing leadership capacity for sustained transformation, The Execution track focuses on launching and developing high-performance project, product and operational teams.  This track is the one that most of our clients use when they run Agile pilot programs and is a critical component of getting quick wins for the organization.

Groundbreaking works such as The Wisdom of Teams (Katzenbach & Smith), The Five Dysfunctions of a Team (Lencioni) and Drive (Pink) have served well to distill the essential requirements of high-performance teams.  Scrum, Kanban, and OpenAgile are proven frameworks that optimize the value of teams and create the necessary working agreements to help teams reach that high-performance state.

The Delivery Team track of the Real Agility Program creates new, cross-functional, multi-skilled, staff-level teams of willing individuals.  These teams are responsible for delivering value—business results and quality.  Individuals are committed to the performance of the team and the organization.  Teams develop the capacity to self-organize and focus on continuous improvement and learning.  A team is usually composed of people from various roles at the delivery level.  For example, and IT project team might be composed of people whose previous* roles were:

  1. Project manager
  2. Business analyst
  3. Software developer
  4. Tester
  5. Database developer
  6. Team lead
  7. User experience lead
  8. Intern

* These roles do not get carried into the new delivery team other than as a set of skills.

The track begins with establishing pre-conditions for success including executive sponsorship, availability of team members and management support.  Team launch involves a series of on-the-job team development workshops designed to enable the teams to create their own set of values, working agreements and high-performance goals.  Teams are guided in the creation of their initial work backlogs, defining “done”, estimation and planning and self-awareness through the use of a collaborative skills matrix.  The teams are also assisted in setting up collocated team rooms and other tools to optimize communication and productivity.

Qualified coaches assist the teams to overcome common issues such as personal commitment, initial discomfort with physical colocation, communication challenges of working with new people in a new way, management interference and disruptions and appropriate allocation of authority.  This assistance is delivered on a regular schedule as the team progresses through a series of steps in the Execution track process.  Usually, these steps take one or two weeks each, but sometimes they take longer.  A team that needs to get to a high-performance state quickly might go through the entire program in 10 or 12 weeks.  In an organization where there is not the same urgency, it can take up to a year to get through the steps of the track.

The coaches for this Execution track also help management to resist and overcome the strong urge to manage the problems of the teams for them.  In order to develop through the stages of team development, teams need to be effectively guided and encouraged to solve their own problems and chart their own courses towards high-performance.

The goal of the Execution track of the Real Agility Program is to help the team go through the stages of forming-storming-norming and set them up to succeed in becoming a high-performance team.  Of course, to do this requires some investment of time.  Although the Execution track is meant to be done as on-the-job coaching, there is a 5% to 20% level of overhead related to the Real Agility Program materials themselves.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Categories: Blogs

Package Management And Dependencies: Still A Human Problem

Derick Bailey - new ThoughtStream - Mon, 03/24/2014 - 15:39

In spite of all the advances that we’ve had in package management for software in the last however-many-years, managing dependencies within a project is still not a 100% solved problem. There is still, and may always be, a human element to the problem and solution. 

A Version Problem

I spent about 5 minutes panicking as I saw SignalLeaf‘s media server returning a 500 Internal Server error after doing a deploy, recently:

Screen Shot 2014 03 24 at 8 20 08 AM

This had me scratching my head and wondering. How is it that my local version works and when I deploy it breaks? I’ve seen this happen before, though, so the first thing I did was check to make sure that package.json file was set correctly. I wanted to make sure it didn’t have the default “*” setting for the jade package… and it didn’t.

Then I started wondering, which version was actually installed on my local box. So I ran npm list and found out that I had jade v1.1.4 installed on my local machine. Apparently I had updated my package.json file with a newer version of jade but never installed it locally. When I deployed to heroku, it grabbed the version specified and started throwing the error above. I corrected the package.json to use jade v1.1.4 and re-deployed. The site came back up and all was well … or, well… everything except for my faith in package managers.

A Human Problem

This is only one of a dozen problems that I’ve had with package managers lately. From apt-get on Ubuntu Linux, to homebrew on mac, to npm, nuget, rubygems, composer and a few other package managers for both operating systems and language platforms / runtimes, I seem to continuously run in to problems. The thing that I’ve realized about these problems recently, is that most of them are still human problems.

Humans still specify the versions of things that they need – both for software packages and dependencies in those packages. Humans also specify the version of package they are writing. When you combine machines trying to faithfully reproduce the intent of a human, with a human’s consistent failure in expressing intent correctly (we all make assumptions that we don’t recognize), you end up with hilariously bad situations.

  • One package won’t use Semantic Versioning (SemVer), while another does and depends on the first
  • A developer decides to put “*” as the dependent version for a package
  • Someone else adds breaking changes to a package that is supposed to using SemVer and only updates the 3rd dot number

The list of problems goes on and on and one, because package managers are still a human problem.

Still Worth Using

Don’t get me wrong, here. I’m not saying package managers aren’t worth it or don’t solve any problems. They do solve a problem of downloading and making available specific packages at specific version numbers. They also attempt to satisfy all of the dependency needs of the package your installing. But there are still problems with these package managers, and there is still a human element to them – and I believe there always will be a human element involved. Unless we can take people out of software development (yeah, right… artificial intelligence, anyone?), we will always face the uncertainty of humans being involved in our software. Keep this in mind as you build packages, set version numbers and list dependencies. 

     Related Stories 
Categories: Blogs

Gamification for your Agile Journey

Gamification adapts game concepts to nongaming situations to engage employees and motivate them to improve their performance and achieve a beneficial behavior. It rewards employees for completing performance levels with points, badges, privileges, and sometime monetary incentives. Gamification can be deployed as one of the possible techniques to engage employees as part of your Agile Journey.
The key to gamification is that it must be driven by a clear business goal with a clear outcome.  With the context of Agile, the goal with gamification is to encourage employees to become engaged in Agile, with the outcome of ‘giving back’ to the Agile community.  While your Agile journey may start with training and coaching, you eventually would like employees acting as Agile Champions to give back and start sharing their knowledge and experience within their colleagues.

As an example, let’s say you have established an Agile Education Vision with the goal of getting employees to give back to the Agile community.  As one technique, you decide to use gamification to motivate and engage employees to become Agile Champions and give back to their local community. Let's posit five levels of Agile Champion and the points needed to achieve each level:
  • Steel: 5 points
  • Bronze: 25 points
  • Silver: 50 points
  • Gold: 100 points
  • Platinum: 250 points

By achieving certain levels, a precious medal badge is earned which the employee can add to their signature line and receive an award to support the behavior, both to recognize this achievement. The vision lays out the following education elements, together with the points earned by completing each one:
  • Take the online “Agile Overview” for awareness: 5 points
  • Attend Scrum Master, Product Owner, team, or manager training per your role: 20 points
  • Take a variety of short online courses such as “How to Write User Stories” to build skills: 5 points each 
  • Attend a 45-minute seminar/webinar on various Agile topics such as “Lessons Learned from Sprint Retrospective” to understand process: 5 points each
  • Write an internal blog article and share with the internal Agile community: 25 points
  • Create and present a webinar and share with the internal Agile community: 50 points

Notice that by taking the “Agile Overview,” the participant immediately becomes Steel level. This gets them into the game which may motivate them to keep playing. Also notice that the bigger point items promote giving back to the internal Agile community. This preferential valuation aligns with the goal of giving back while building their Agile knowledge along the way.
If you use gamification, ensure the achievement is real, that it helps the employee with their work, and is aligned with your Agile goals.  Finally, please remember that gamification is just one technique within your Agile toolkit in building an Agile community and having a successful Agile journey. 

PS - to read more about how Gamification can help you in your Agile journey, consider reading Chapter 16 of the new Agile book entitled Being Agile.  

Categories: Blogs

Functional Programming in Java – Venkat Subramaniam: Book Review

Mark Needham - Sun, 03/23/2014 - 23:18

I picked up Venkat Subramaniam’s ‘Functional Programming in Java: Harnessing the Power of Java 8 Lambda Expressions‘ to learn a little bit more about Java 8 having struggled to find any online tutorials which did that.

A big chunk of the book focuses on lambdas, functional collection parameters and lazy evaluation which will be familiar to users of C#, Clojure, Scala, Haskell, Ruby, Python, F# or libraries like totallylazy and Guava.

Although I was able to race through the book quite quickly it was still interesting to see how Java 8 is going to reduce the amount of code we need to write to do simple operations on collections.

I wrote up my thoughts on lambda expressions instead of auto closeable, using group by on collections and sorting values in collections in previous blog posts.

I noticed a couple of subtle differences in the method names added to collection e.g. skip/limit are there instead of take/drop for grabbing a subset of said collection.

There are also methods such as ‘mapToInt’ and ‘mapToDouble’ where in other languages you’d just have a single ‘map’ and it would handle everything.

Over the last couple of years I’ve used totallylazy on Java projects to deal with collections and while I like the style of code it encourages you end up with a lot of code due to all the anonymous classes you have to create.

In Java 8 lambdas are a first class concept which should make using totallylazy even better.

In a previous blog post I showed how you’d go about sorted a collection of people by age. In Java 8 it would look like this:

List<Person> people = Arrays.asList(new Person("Paul", 24), new Person("Mark", 30), new Person("Will", 28)); -> p.getAge())).forEach(System.out::println)

I find the ‘comparing’ function that we have to use a bit unintuitive and this is what we’d have using totallylazy pre Java 8:

Sequence<Person> people = sequence(new Person("Paul", 24), new Person("Mark", 30), new Person("Will", 28));
people.sortBy(new Callable1<Person, Integer>() {
    public Integer call(Person person) throws Exception {
        return person.getAge();

Using Java 8 lambdas the code is much simplified:

Sequence<Person> people = sequence(new Person("Paul", 24), new Person("Mark", 30), new Person("Will", 28));

If we use ‘forEach’ to print out each person individually we end up with the following:

Sequence<Person> people = sequence(new Person("Paul", 24), new Person("Mark", 30), new Person("Will", 28));
people.sortBy(Person::getAge).forEach((Consumer<? super Person>) System.out::println);

The compiler can’t work out whether we want to use the forEach method from totallylazy or from Iterable so we end up having to cast which is a bit nasty.

I haven’t yet tried converting the totallylazy code I’ve written but my thinking is that the real win of Java 8 will be making it easier to use libraries like totallylazy and Guava.

Overall the book describes Java 8′s features very well but if you’ve used any of the languages I mentioned at the top it will all be very familiar – finally Java has caught up with the rest!

Categories: Blogs

Adventures in Commuting

I rested my head against the window, drowsy from a long day, full tummy, and steady hum of the train. My husband sat next to me absorbed in a game. It’s a long ride from San Francisco, where we work, to Pleasanton, where we live. I thought I might take a nap.

A disembodied voice crackled, announcing the next station: “West Oakland.”

The train stopped, the doors opened. I watched the passengers. The train car was about half full. A few people got off. Three black youths, a girl and two boys, got on. They were talking animatedly, happy. All three were well-dressed: fashionable clothes that looked new and fit well. Tight black pants. Caps. A little bling. They’d taken the time to look nice, and they were out for a good time.

One of the boys sat while the girl and the other boy stood, balancing by holding onto the straps suspended from the ceiling of the car. They talked and joked together. I felt a little voyeuristic watching them share this private moment of fun, but I couldn’t help myself. I was too taken with their delight and energy. Their faces lit with joy as they laughed. The girl and the boy hung from the straps and swung their weight around, enjoying the interplay of gravity and momentum of the train and their own upper body strength.

The girl clung to the strap then braced her other hand on the side of the train. Walking her feet up the train side, she executed an impressive flip. She did it again, obviously pleased with herself. “You try doing that in heels!” she crowed. She did it again. I noted with admiration that she was wearing boots with 5″ heels.

I guessed the kids to be somewhere between 15 and 20. It’s an in-between age. Young enough to treat a train as a jungle gym but old enough for a night out on their own. I thought about my own kids, about the same age.

The disembodied crackling voice announced the next station: Lake Merritt. The train stopped. The kids stayed on. The train started again. The train abruptly came to a screeching halt. “That’s not good,” the passenger in front of me muttered. I looked around but couldn’t tell why we were stopped. I leaned my head back against the window; my husband stayed immersed in his game. The trains don’t run on time here. Stopping wasn’t unusual.

Two BART police officers stepped onto the car. Another guy, a passenger, trailed behind them. The passenger with the cops said something I couldn’t hear and gestured toward the three youths. He was a mousy white guy in a button-down oxford shirt, corduroy pants, and a fleece vest. He looked like the kind of guy who drives an SUV with Save the Planet bumper stickers.

The first police officer addressed the youths. “There’s been a complaint. I need you to step off the train.”

“What’s the complaint?” the girl asked.

“We didn’t do anything,” the boy said.

“There’s been a complaint,” the police officer insisted. “Please come with me.”

“What’s the complaint?” the girl repeated.

The mousy passenger who had made the accusation faded back. I didn’t see where he went. Now it was just the cops and the kids.

“We got a complaint that you were asking for money.” The cop’s voice carried.

“We didn’t do anything!” the boy repeated, louder.

“Please come with me,” the cop insisted. “This train can’t move until you get off.”

The crowd on the car grew restless, impatient. The two cops flanked the three youths and attempted to escort them off the train. For a minute, it looked like the kids were going to comply. The boy who was seated stood, headed toward the open door, but then changed his mind. “I didn’t do anything. I was just sitting there,” he said. He got back on the train.

The girl’s face had gone from joy to furor. “It’s that racist white guy,” she yelled, loud enough for the whole train car to hear. “We didn’t do anything, but he thinks we did because we’re black.”

A passenger stood up, Asian, “They really didn’t do anything,” he said to the cops. Then to the kids: “Let’s just step off the train so they can make their report.”

Another passenger stood up. A black woman. “Really, officers, these kids didn’t do anything.”

By this time I was on the edge of my seat. It was so unfair. These kids were just out for a good time. They had done nothing besides being full of energy and life. They hadn’t asked for money. They were being harassed by the cops for something they had not done.

I’m still not sure what made me decide to act on my sense of injustice. Maybe I arrogantly thought the police would listen to me, a middle-class, middle-aged, white woman. Maybe I saw the faces of my own kids in the black youths and imagined them being detained on hearsay. Whatever the trigger, I stood up, moving past my husband who looked at me quizzically. I walked up the train aisle to the officer who had been barking orders.

“Sir, they really didn’t do anything. They just got on at the last stop.” My voice was steady. Calm. Quiet. Pitched for the circle of people involved, not for the rest of the train. Internally I was amazed that my adrenaline wasn’t amped up, that my voice was not shaking. I don’t normally confront cops. It is not at all like me to tell a cop how to do his job. I couldn’t believe I was confronting a cop and not even nervous about it.

By this time the crowd on the train was growing antsy. A few were calling for the kids to get off the train so they could get where they were going, but far more were calling for the cops to leave the kids alone. Several more passengers stood up and started shouting at the cops:

“These kids didn’t do anything!”

“Leave them alone!”

“Racist white guy can’t tell blacks apart!”

“It must have been someone else!”

“Let the kids go!”

I felt self-conscious standing in the middle of everything. I’d played my bit part in the unfolding drama. I returned to my seat.

A woman on the other side of the car leaned over toward me, “I could have done that,” she said. She was white like me, graying hair cut shoulder length in a bob. She looked like she could live in the house next door in my white-picket-fence neighborhood.

“I’m sorry?” I was confused by her words. What does that even mean, I could have done that? If you could have why didn’t you? Did she mean that she could not have done what I did?

“I could have done what you did,” she repeated.

I smiled and nodded. I didn’t know what else to say.

My attention turned back to the growing situation. More passengers had stood up to defend the kids. Another BART police officer entered the car. The increasing tension and buzz from the crowd made it hard to hear. I realized that there were several more police officers waiting on the platform. The situation had escalated rapidly. This could become ugly.

“CHECK THE BUCKET,” the girl shouted.

For the first time I noticed that the kids had an amplifier and a bucket with them, and suddenly I saw a missing piece of the puzzle. The kids were street performers. They weren’t out for a night of clubbing. They were dancers.

Sometimes street performers come onto the BART trains. They strut up and down the aisle, put on a show, and ask for money. I personally find being a captive audience to these shows annoying. I never give the performers money because I don’t want to encourage it. But I did not realize that such behavior warranted police intervention on this scale.

Nor did I think that these kids had been dancing for money on this train. I looked around for the accuser but couldn’t see him.

I was incensed by the entire situation. The accuser had disappeared, the situation was escalating, and these innocent kids were now targets.

“This isn’t right,” I told my husband. I stood up, shouldered my backpack in case I decided to leave the train, and pushed past my husband’s knees for the second time. Without even thinking about whether or not my husband would follow me or would be upset with me for getting involved, I stepped into the situation again.

I sidled up to the cop who had originally been barking orders and who was now standing between the kids and the rest of the passengers.

“They really didn’t do anything,” I said into his ear. “They didn’t. This isn’t right. I will be happy to make a statement. What can I do to help?”

The cop turned to me. “They might not have done anything originally,” he said, “but now they are resisting. If they don’t get off the train we will have to arrest them.”

Another police officer entered the train. The mood of the passengers was growing dark, roiling. It became a palpable thing, shifting energies threatening to spill over into violence. My stomach fluttered.

I turned around, realized that half a dozen people had their cell phones out, recording the incident. I idly wondered if I would show up on youtube videos. I decided I didn’t care. This wasn’t right and I wouldn’t stand for it. These kids were being detained, harassed, and possibly arrested all because the mousy guy in the fleece vest didn’t like being bothered by dancers panhandling on BART. These kids might have danced on BART at some point, but not tonight, not on this train. They didn’t deserve this.

Another officer entered the train. It was now five officers to the three kids. The Asian passenger who had originally stepped up to intervene turned to the kids, “Why don’t we get off the train and get this handled. Then we can all get onto the next train.”

The police closed their circle, puffing themselves up, herding the kids to the exit. I followed them to the door. I was about to step off the train. I turned back to see if my husband was paying attention. He was staring at me, his face open, questioning. “This isn’t right,” I mouthed at him. He stood up, following me.

I turned my attention back to the kids. The cops had one of the boys in an arm lock and pressed him up against the wall of the station. It looked like it hurt. They had the girl surrounded. I couldn’t see her, but I could hear her screaming. I heard another voice — the other boy? the Asian passenger who had intervened? a cop? — telling her “This isn’t worth it. Stop struggling.”

I stepped off the train onto the platform.

The cops who had the girl surrounded had her hands behind her back. She was struggling and screaming. They began half pulling, half dragging her down the platform toward the station exit. “LET GO OF ME,” she shouted. “LET GO OF ME LET GO OF ME LET ME GO!”

An officer stood in the middle of the chaos just looking, sizing it all up. He was new on the scene. He was also the only officer not in the middle of the chaos. I walked up to him. “Sir, they didn’t do anything,” I said. I watched his face. Dark skin. Brown eyes. A guy who’d been having a quiet night. He turned to me.

“You’re a witness?” he asked.

“Yes sir. I was on the car. These kids didn’t do anything. This isn’t right.” The girl was still screaming. Each panicked shriek felt like shrapnel in my soul. That could be my daughter, I thought. So very not right. “I will be happy to make a statement,” I said.

“OK,” the cop replied. He took out a notebook, asked me my name. He had to ask me to spell my last name a second time. I handed him my driver’s license to make things easier for him. He started taking notes, then looked up at my husband and me. “I left my recorder in my office,” he said. “Would you be willing to go there to make a statement?”

I agreed immediately. To my surprise, my husband agreed as well. “Of course,” he said. We would probably be an hour late, or more, getting home. This was worth it.

We followed the officer off the platform, past the turnstiles, and through a door marked “authorized personnel only.” He led us down a maze of corridors, past a bank of cubicles, and into his office. As promised, he took out a recorder and interviewed us for a verbal statement. My husband and I each told our version of the events. They lined up. Each of us emphasized that the kids had done nothing wrong.

“Let me just clarify a few points,” the officer said after we finished our statements. “In your opinion, did the officers use excessive force at any time?” I said they had, citing the painful hands-behind-the-back restraining technique and the panicked girl screaming. My husband said they had not, but pointed out that the officers should have just let the kids go when so many passengers testified that the kids were innocent.

The officer asked a few more questions: had the officers used mace, batons, or physical violence on the kids? had they acted unprofessionally?

We finished the interview, the officer escorted us back into the station, said that internal affairs would probably be contacting us in connection with the investigation, then said goodbye.

As we waited for the next train, I played over the evening in my mind.

I realized that the statements we made existed only on a recorder in the cop’s office. The kids wouldn’t know we made the recorded statement. If they got lawyers, the lawyers wouldn’t know. Our testimony might never be heard by anyone involved in the case against the kids.

The more I played over the questions that the officer had asked us, the more I realized that the questions were all about the conduct of the other officers, not about the kids and their innocence.

The internal affairs investigation would, no doubt, turn into a huge deal. The situation had escalated so rapidly, fueled by racial tension. So many people had recorded videos. The train had been halted for 15 minutes or more. Passengers were irate. There would be much attention on the conduct of the cops.

I didn’t care about the cops. I wanted to help the kids.

Somehow, I doubted that I had.

Next time I see dancers on BART, I’m giving them whatever is in my wallet. I’ll think of it as their defense fund.

Categories: Blogs

Agile Leadership Dashboards: Post 1

Scrum Log Jeff Sutherland - Fri, 03/21/2014 - 18:41
I am having lots of conversations these days about executive dashboards for Scrum…what does a leadership team really need to know in order to do their job well, and how can teams provide that information without wasting valuable of time preparing reports?  Within these discussions, there are also nuances such as: what agile metrics might actually be dangerous to share with management because they can drive unintended consequences?  And what metrics should or shouldn’t be linked to incentives?

With these debates as a background, I am embarking on a regular series of posts to explore the subject of agile metrics and leadership dashboards further.  For this, I will be drawing specifically on experiences setting up our own dashboard at Scrum Inc. and working with a large tech client (who shall remain anonymous) to set up an agile executive reporting tool for their C-suite leadership.  I welcome everyone to join in the conversation and share your own experiences, both positive and negative, in the blog comments.  I will try to weave these into future posts.
To start, what are the goals of a leadership dashboard?  Like a good user story, it is important to have a clear vision of the desired outcome, and a set of acceptance criteria so that you recognize success when you see it.  Particularly if you are using agile to develop the dashboard incrementally, you need to know when your latest increment is “good enough.”
At the most basic level, leaders need to accomplish three objectives:
  • They need to establish and maintain a compelling vision that aligns the organization around a shared sense of purpose.
  • They need to maintain visibility of how the organization is progressing toward the realization of that vision, and make course adjustments as needed to ensure progress.
  • They need to support motivation and accountability within the organization.

An effective leadership dashboard directly supports the second objective, but its can also help deliver the third objective, and should be informed by the first.

To my mind, a successful dashboard should provide leaders with the relevant context and metrics they need to make informed decisions.  It should be updated on a frequency that meets or exceeds the required decision-making cadence.  Finally to the extent possible, the dashboard should be assembled from data that teams are already collecting to inform their own process and pulled automatically to minimize distraction from producing valuable new product.
Relevant ContentI will definitely revisit the topic of potential metrics to include in a dashboard in much more detail in future posts.  For this discussion, suffice it to say that top-level metrics should answer the key questions of:
1) Are we producing the right product(s) for the customers we are trying to serve; 2) Are we prioritizing our efforts and applying our resources correctly given what we think we   know about the market and our competitors; 3) Are we making consistent progress towards our strategic goals; and 4) Are we doing all of the above in a way that we can sustain for the long run? 
Metrics that answer or inform these questions help leaders make better strategic decisions.  Extraneous metrics are at best a distraction, and at worst cause leaders to make bad decisions.
Update CadenceSome decisions only need to be made once a year, such as “should we renew our annual contract with…?”  Others need to be made monthly, daily, or in response to real-time events, such as “how do we restore service given an outage that just occurred?”  A truly great dashboard provides the current snapshot of key metrics with the most relevant data being shown.  Real-time decisions need data from a few moments ago, whereas monthly financial decisions are better made with the recent month’s complete data rather than a partial view of the current month’s results.  Deliberately matching update frequency to decision cadence brings the most powerful data to the right place with the least amount of effort.
AutomationWe speak with far too many teams that complain about the onerous reports they are asked to produce for senior leadership.  The typical complaint is that leadership wants updates on a number of metrics the team never uses for its own purposes, so this data must be gathered, calculated, and presented manually.  The team sees this as a huge waste of time to produce metrics that don’t even reflect reality on the ground.
The Scrum process throws off enormous amounts of high quality data, such as velocity, team happiness, planned backlog, defect and impediment lists, and business value.  Most teams already collect this data in software tools with API interfaces.  Other than the first few iterations of a new dashboard where the metrics and presentation are still being refined in coordination with leadership stakeholders, there is no good reason dashboard data can’t be pulled, calculated, and presented automatically.

As I mentioned, this is just the first of many posts on this topic.  If you want to dig deeper, feel free to check out our past online course on "The Agile Leader's Dashboard".

-Alex Brown

Categories: Blogs

The Mark of a High-Performing Team

Rally Agile Blog - Fri, 03/21/2014 - 18:33

Have you ever heard of Tuckman’s stages of group development? According to Tuckman, teams must go through four stages -- Forming, Storming, Norming, and Performing -- in order to grow and develop as a collective. This quarter, my team entered the ‘Performing’ stage: we gelled. We finished our quarterly objective early and the feature release has been a success for users.

So, what does a performing team look like? And how did I know that my team had entered this stage?


First, I’d like to share with you where Rally was when I started here as an engineer almost three years ago. We had just switched over from full-on Scrum to Kanban. In Scrum, timeboxed commitments are king and predictability rules. Kanban is a little different in that your team pulls the work as you finish the previous piece of work, and it flows through the system much like a car flows through a manufacturing plant before it rolls out the door. Switching to Kanban brought its own problems: commitments and timeboxes became bad words, and we lost predictability. Furthermore, teams had no shared sense of urgency for time commitments; developers were shielded from much of this pressure by the product owner.

A little over a year ago I became product owner. I’m still learning as I go, but one thing I know is that dates matter. Everyone wants to know when customers are going to get access to a feature. They want progress on how the beta’s going.

During my first months as a product owner I would show up with a feature, plan it with the team, and have them pull it. Though features took a while, my team never questioned why we were pulling certain features. They assumed that I had done my due diligence on the customer development side, and figured that I understood the customer value we were providing.

Then one day, everything changed.

Sales came to Product with a customer escalation, an urgent request to help one of our customers find a solution to a major obstacle. I had some urgent calls with one of our VPs, a few directors, and the customer, and we started brainstorming possible ways to quickly fulfill their needs. We were given a date: show progress on the solution by the end of Q1.

Once we understood the need and I budgeted my team’s time, I and a few members of the UX team went to visit the customer to learn more. We came back with a good understanding of an MVP (minimum viable product) and entered our Q1 planning with a decent list of stories.

In planning, my team started examining the work and subsequently began to pull it apart. Everyone knew there was a date looming in the near future; the customer was expecting to get something by the end of the quarter, and this changed the game. Suddenly the question became, Is this absolutely necessary for the first release? Can we delay this story until the must-haves are complete? By the end of planning, the size of the feature went from 21 stories down to 11 stories, and everyone felt confident that it was doable.

2179067948_dae0f9cd19.jpg(Flickr Library of Congress, CC)

The examining didn’t stop there. Every week in planning, the team questioned my initial acceptance criteria along with our priorities. We continued to ask, Is this the most important story that we can pull right now? How much do customers really want this? Throughout the development process, the team actively helped to define the feature.  

Team members came to beta calls to find out how their work was received by users. They listened thoughtfully, and took action afterwards. They continued to ask questions in planning: Are we sure this is the most important implementation for this story? Can we split this off and prioritize it later?

The team also grew comfortable telling other developers, No, we can’t help you with that defect right now, because we have a feature to do. Their number one priority was making their commitment. We all shared the sense of urgency.  

We released our feature, early -- not because it was perfectly planned at the beginning of the quarter, but because the team felt ownership and responsibility for its success. It was our MVP and then some.  

Rally has a concept we call “delighters.” A delighter is a part of a feature that isn’t necessary, but will really please and delight the user. Not only were we able to release the MVP of the feature, but we released several delighters that hopefully made our customers’ lives a lot easier.

It feels good to be a part of a performing team. I always want the team to feel collective ownership for the success of a feature. My team members should feel comfortable questioning our priorities and what’s in my head, and I should have a thoughtful answer for them. I always want to encourage them to listen to customers and hear both positive and negative customer feedback. This will only make us feel more invested in our product and the features we’re producing, and that’s certainly one mark of a high-performing team.

  Stephanie Tanner
Categories: Companies

Gates or Jobs?

TargetProcess - Edge of Chaos Blog - Fri, 03/21/2014 - 11:40

This world has always been in need of role models. Heroes that we want to look up to striving to follow their path, their principles and ethos (if we mean business in this life, of course). For quite many years, tech entrepreneurs and IT start-up founders worship one iConic hero wrapped in myths and adoration, with zealots standing in lines any time a new iPhone is out; and it seems they’d tear apart anyone who dares not to like Apple products.  As great and outstanding an achiever and innovator as Steve Jobs is, his life was far from being a glossy success story, judging by what people say and write. There’s something tragic about him, a Prometheus-like charisma, as if he’s torn his heart out of himself, lightning people’s way with a technology wonder, and then perished, chained to the rocks of self-oblivion.

May God bless Steve Jobs’ memory and let him rest in peace. There’s this other guy who looks rather laid back, than tragic, and who goes on serving the humankind. Being born same year as Jobs, 1955, he still lives and does things that reach far beyond designing devices, or making a religion out of them. Quoting from a recent Gates’  interview to the Rolling Stone magazine:

At 58, Bill Gates is not only the richest man in the world, with a fortune that now exceeds $76 billion, but he may also be the most optimistic. In his view, the world is a giant operating system that just needs to be debugged. .. Huge systems, whether it’s Windows 8, global poverty or climate change, can be improved if you have the right tools and the right skills. The Bill & Melinda Gates Foundation .. is like a giant startup whose target market is human civilization.

I am old enough to have witnessed how Microsoft evolved in the 90′s, remembering this buzz about monopolism, and the image painted out of Bill Gates as a ruthless shark.

This dynamics changed closer to the mid 2000′s. Gates was moved backstage, as if a by a scheduled scenery swap in a theater play, and Jobs came into spotlight. There’s a rush of love for Apple, people adore iPhones, and Steve acquires his ardent fanbase. He drives the Apple empire with his spirit to stand out, to leave his technological footprint in this world, and as a result he burns himself out and falls prey to cancer. We’ve also witnessed the rise of Mark Zuckerberg, but I’m deliberately not letting Mark in to the super-heroes pantheon for one obvious reason: he’s only 29, and his success is yet to stand the test of time. Although, I’d say humanity would hardly benefit too much, if at all, from Facebook and face recognition technologies (maybe security services will). Let’s see what happens to Mark as he lives up to the age of 45, at least.

Back to Jobs and Gates. They say: “The best revenge is a life well-lived”.  We’re not talking about a revenge here, rather about a wise path to live this life to the fullest, as a tech, and then global entrepreneur, and to have a broad outlook on the world, going  beyond the realm of digital devices and designs. Is it wise to deify a person who lost his fight to stresses, and sacrificed himself to the altar of all things “I”?  Probably, there’s no finite answer to this question. It might be a matter of personal preference: some people feel more affinity with tragic heroes, who light up grey landscapes brightly and then fade away;  some people appreciate the steady path of living and exploring, managing to care of themselves in such a way, so as to have as many years in this life as it can get, because more years bring  more opportunities to serve the others.

There, I nailed it. Here’s the main difference between our super-heroes. Looks like Steve Jobs’ goal was to leave his footprint and be remembered for that. Bill Gates, on the contrary, seems to be more service-oriented in the way of humility.  At least, the initiatives that he supports are a proof for that. Speaking of footprints, one of the projects that Bill Gates funds is a zero-CO2 emissions research, something that is very unlikely to be financed by a private or a state corporation.

All things considered, if we were to come up with the ultimate role model for aspiring tech entrepreneurs, whom would we choose now: Bill Gates or Steve Jobs?

Image credits:

Related articles:

When Intensity Pays Off

Why Fast Is Slow

Continuous Problem-Solving Is No Accident

Project Manager or Tech Leader?

Categories: Companies

How The ScrumMaster Develop a Team

TV Agile - Thu, 03/20/2014 - 23:20
This video describes the role of a Scrum Master and the journey an agile team and the Scrum Master is on. It uses a 2D chart to describe the correlation between the team maturity and the level of self-management. Video producer:
Categories: Blogs

Implementation of Agile & Scrum at a Government Agency

Scrum Expert - Thu, 03/20/2014 - 22:54
Like many IT organizations in state government agencies, this New York State Government Agency primarily used Waterfall. I implemented the agency’s first agile projects. I was challenged by the agency’s unique environment, learned lessons, discovered systemic problems, overcame organizational obstacles and changed misconceptions. I will discuss what I’ve learned during this award-winning project and make recommendations for others in bureaucratic companies and government agencies. The agency’s projects are moving to agile/scrum and the institution’s IT group is incorporating agile into its PM and SDLC methodologies.Video producer:
Categories: Communities

An open letter to the Editor in Chief of Dr. Dobb's

Powers of Two - Rob Myers - Thu, 03/20/2014 - 20:34
Here is the letter I just sent to Andrew Binstock at Dr. Dobb's regarding this editorial:

Hello Mr. Binstock,

I agree with your conclusions regarding the productization of Agile, and the zealotry regarding various sets of practices.  Within every community or body of knowledge, it seems, strong practices become the dogma of the enthusiastic, and then the core value gets lost in illogical debates where everyone is trying to be “right."

I’d like to take a moment of your time to provide some of my experience with the practice that you selected (likely not arbitrarily) as an example of the zealotry:  Test-Driven Development (TDD). Indeed, there is a lot of confusion and passion and zealotry regarding this practice.  I feel no need to defend, exactly, but I believe I understand much of the enthusiasm, and much of why most people can’t really articulate their love for TDD.  One reason why it’s so confusing even for those passionately in favor of TDD is that the real value appears as a “sub-practice” of TDD. (I’ll come back to that.)

I’ve been writing code since 1976, and in the “Agile” space since 1998, when I first experienced TDD (or “test-first” as it was known then).  Unlike many of my bright-eyed young Agile colleagues, I spent half my career crafting quality, nearly-defect-free code before that point, without TDD.  Here’s what I’ve noticed over time:

1. From “All in your head” to "fast feedback."

Pre-TDD, I spent a lot more time running various branches and permutations through my mind, or in a flowchart, or in a sequence diagram, and in review with others on my team.  All great practices, and necessary in the days when it took an hour to compile the code.

What I do with test-first coding is describe the outcomes of small pieces of behavior in my code, then allow those passing tests to provide confirmation of my investment in that behavior.  I no longer have to keep the permutations and possibilities in my head.  Great burden lifted.  We’ve long had compilers to provide a red flag when I make a syntactic mistake, and now fast tests provide similar near-instantaneous feedback when I mistakenly change run-time behavior.  To me, TDD feels like a natural progression of good practices for the computer scientist, and the professional developer.

2. From slow and expensive to fast and cheap.

The code I was building pre-TDD was probably a little more complex than Internet protocols, but not much. We did supercomputer protocol stacks for a variety of machines, some of them with 36-bit words and 9-bit bytes. Two modes: Character and binary, but character was also subdivided into translations between any two of ASCII, EBCDIC, and BSD.  Oh, how I would have loved a (really fast) implementation of something like Strategy or maybe there’s even a Bridge hiding in there?

Nowadays I find our products to be, in the aggregate, far more complex than in the 80’s: Voice-recognition, search, security, multi-platform, interesting business rules regarding financial transactions, regional laws, internationalization…  Far too much changing (or potentially changing) far too quickly for us to do more than paint broad-stroke architectures at the high level; and far too complex and dynamic for our developers to be doing code-and-fix-and-update-the-UML.-that-no-one-reads.

Overall, TDD now feels far more natural to me.  I play a game with my code:  “You can’t do this yet,” I say. My code replies “You’re right, I fail at that.” I then tell my code how to do that, and together we confirm that it works, and simultaneously confirm that I haven’t broken anything my code has learned over the years. Then I see if the introduction of that implementation is asking to be blended more cleanly into the code: Refactoring is the oft-neglected sub-practice of TDD. Each time I reshape the design to accommodate this new behavior or the next, I run the tests to let my code confirm that it hasn’t lost any capability.

In fact, “relentless refactoring,” i.e., the constant application of good design practices, is the real “must have” for Agile software development. How else adapt to fresh new unexpected requirements without being able to reshape code? But without some form of fast, automated, deterministic safety-net of tests, relentless refactoring is mere dangerous unprofessional hacking. Ergo, test-first coding.

I’m not attached to TDD or even “Agile" as static, dogmatic sets of practices for the very reason that I already know it was once less efficient than pure human brain-power. Someday we will look back and laugh at our zeal. But I think TDD has some good life left to it, because of the outcomes:  Comprehensive, executable engineering documentation describing all the discrete behaviors of the system in a non-combinatorial fashion; and the ability to change the code rapidly and confidently.

Thank you for your time and kind consideration.

Rob Myers
Categories: Blogs

Perforce Introduces Hybrid Version Control - Thu, 03/20/2014 - 18:12
Perforce Software has announceda platform for hybrid version control. Unique capabilities across the Perforce suite of solutions help developers use Git alongside Perforce's native versioning protocol (P4) without hindering DevOps teams from implementing and accelerating their continuous del ...
Categories: Communities

TechExcel Announces DevSuite 9.3 - Thu, 03/20/2014 - 17:31
TechExcel has announced DevSuite 9.3, the latest edition of its ALM platform with integrated Requirements, Quality and Agile Management. DevSuite 9.3 includes usability enhancements and performance improvements that enable companies to more effectively and efficiently manage requirements, develo ...
Categories: Communities

Assembla Tips and Tricks to Work Smarter and Faster

Assembla Blog - Thu, 03/20/2014 - 16:35

assembla tips

Assembla has many powerful and hidden capabilities that can help you get your work done more efficiently. In order to get those most out of your Assembla projects, here are a few tips and tricks to help you and your team work smarter and faster. Do you have any tips and tricks you want to share Email or tweet your tips with hashtag #AssemblaTips.

Get attention from your team members with @mentions. For extra certainty, add a ! at the end like @adam! or @support! to instantly send an email to that member or group. 

Type @ and start typing a users name virtually anywhere in Assembla to call out users. User get notification alerts in their top bar to signify something needs their attention. Set up labels in the Team tab to mention groups like @support or @admin. 

Focus the attention of your team by setting your project’s default landing page (tool) and arranging the tool tabs so that the most important tools are easy to find. 

Visit the Admin tab of your project > click on the Appearance section > and scroll to the Navigation section. Drag and drop tools to rearrange the order of the tool tabs in the main navigation and select the desired default tool in the “default landing tab is” drop-down. When you have made the desired changed, scroll down and click on ‘Save Changes.’

Illustrate your point by dragging and dropping files on a ticket.

Once a ticket has been created, you can grab any file from your desktop and drop it anywhere on the ticket. This will upload and associate the dropped file to the ticket. 

Edit ticket status values to create custom workflows. Additional status workflows will be displayed on the Cardwall view so you can visually see the status of all work in progress. 

Go to the Tickets tool > Settings sub-tab > Status and Workflows section. You can create new statuses and rearrange the order of your statuses. The order the statuses appear on this page is the order they will appear in the status drop-down on tickets, and the order of the columns from left to right on your Cardwall view.

Get code reviews by setting repository branches as "protected” so only certain team members are able to push commits to a given branch after the code has been reviewed and approved.

Visit the repository’s tab within Assembla > Settings sub-tab > Protected Branches section and define what team members are allowed to perform what action to given branches.

cta tips2

We would love to hear your tips and tricks! Email us at or tweet your tips with hashtag #AssemblaTips.

If you do not have an Assembla project, get started for free.

Categories: Companies

Successful IoC container usage

Jimmy Bogard - Thu, 03/20/2014 - 16:08

Every now and again I here the meme of IoC containers being bad, they lead to bad developer practices, they’re too complicated and on and on. IoC containers – like any sharp tool – can be easily abused. Dependency injection, as a concept, is here to stay. Heck, it’s even in Angular.

Good usage of IoC containers goes hand in hand with good OO design. Dependency injection won’t make your design better, but it can enable better design.

So what do I use IoC containers for? First and foremost, dependency injection. If I have a 3rd-party dependency, I’ll inject it. This enables me to swap implementations or isolate that dependency behind a façade. Additionally, if I want to provide different configurations of that component for different environments, dependency injection allows me to modify that behavior without modifying services using that component.

I am, however, very judicious in my facades. I don’t wrap 3rd party libraries, like a Repository does with your DbContext or ISession. If a library needs simplification or unification (Adapter pattern), that’s where wrapping the dependency helps.

I also don’t create deep compositional graphs. I don’t get stricken with service-itis, where every function has to have an IFooService and FooService implementation.

Instead, I focus on capturing concepts in my application. In one I’m looking at, I have concepts for:

  • Queries
  • Commands
  • Validators
  • Notifications
  • Model binders
  • Filters
  • Search providers
  • PDF document generators
  • Search providers
  • REST document readers/writers

Each of these has multiple implementers of a common interface, often as a generic interface. These are all examples of the good OO design patterns – the behavioral patterns, including:

  • Chain of responsibility
  • Command
  • Mediator
  • Strategy
  • Visitor

I strive to find concepts in my system, and build abstractions around those concepts. The IModelBinderProvider interface, for example, is a chain of responsibility implementation, where we have a concept of providing a model binder based on inputs, and each provider deciding to provide a model binder (or not).

The final usage is around lifecycle/lifetime management. This is much easier if you have a container and ecosystem that provides explicit scoping using child/nested containers. Web API for example has an “IDepedencyScope” which acts as a composition root for each request. I either have singleton components, composition root-scoped components (like your DbContext/ISession), or resolve-scoped components (instantiated once per call to Resolve).

Ultimately, successful container usage comes down to proper OO, limiting abstractions and focusing on concepts. Composition can be achieved in many forms – often supported directly in the language, such as pattern matching or mixins – but no language has it perfect so being able to still rely on dependency injection without a lot of fuss can be extremely powerful.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

“Meet: Scrum”, the Diagram

Learn more about our Scrum and Agile training sessions on

Recently, in my work helping teams to learn and implement Scrum, I have deliberately not been using diagrams.  Having participants create their own ways of describing Scrum based on their own understanding is often a much more powerful approach to learning than showing them a diagram.  If you give someone a map, they tend to assume that all of the exploring has already been done.  If you give them a space to explore, they tend to create their own maps and provide new knowledge about the space being explored.  Maps and diagrams do serve a purpose.  They are useful.  What’s important to always keep in mind is that they should not be regarded as definitive but rather as one  contribution to a body of knowledge that can and should grow.

Anyhow, this isn’t intended to be a blog post about diagrams but rather as a post sharing a diagram that I have created.  One of the participants of a Scrum training that I recently facilitated asked me for a diagram and I said I would find one for him.  All of the other diagrams out there that I could find didn’t exactly convey my own understanding of Scrum.  So, I decided to create my own.

This is the first increment.  I am open to feedback and I look forward to finding out how this interacts with others’ understanding of Scrum.


You can download it at this link: Meet: Scrum.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Categories: Blogs

Mandated Agile - A Contrarian View

Practical Agility - Dave Rooney - Thu, 03/20/2014 - 15:55
There was an interesting exchange recently on Twitter about Agile adoptions/transformations that are mandated. Dan Mezick asserted that: Between 75% and 85% of all #agile adoptions fail to last. 99% of these adoptions are implemented as mandates. Any connection here? I responded, asking for Dan's source to those stats. His answer was that it was "pro coaches" like myself. What ensued was a
Categories: Blogs

Knowledge Sharing

SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.