Where’s the glue?

Teams. What are they and how do they work? They’re groups of people working together collaboratively toward a common goal. They’re held together by strong bonds of commitment, trust, and loyalty. The stronger the bonds, the better the teams. But sometimes, there’s a hidden glue that nobody ever realizes is there. Sometimes, that hidden glue is a single person on the team that really keeps it driving ahead. And most of the time, nobody notices who that person is until they’re not there.

There is a team that I’ve talked with recently that learned this lesson first hand. They were an 8 person team stocked with developers, testers, and UI specialists of varying skill levels. One of the more junior developers didn’t exactly have the mojo when it came to coding, but he was very instrumental in keeping the wheels turning. He took an active role as the “semi-scrummaster” on the team because the actual scrummaster traveled a lot. One day, their organization, in their infinite wisdom, decided that the junior developer wasn’t doing enough development work according to his job description and “downsized” him. After he left, the team noticed that they weren’t accomplishing as much during their iterations and that the value they were delivering to their client had diminished somewhat. The client wasn’t as happy as they had been. After 3 iterations of subpar performance, the team did a retrospective and after some serious soul searching, they realized that the downsized junior developer was the guy keeping the team on track and focused. He was the hidden glue.

So, my point here is to understand that every player on a team has his or her role in keeping the team successful. Some of those roles are obvious and readily apparent. But some are subtle, barely noticeable roles that really keep things well oiled. Don’t ignore your hidden glue. Try hard to identify it and understand what is, because once it’s lost, you may not realize what a good thing you had until it’s too late.

Copy-Paste Reasoning

WrongWay I have a bit of trouble with people who use other people’s opinions and arguments without thinking them through, or without analyzing a situation before applying their copied ideas. And worse than that: some people tell others that they are wrong, without bothering to investigate if their copied arguments actually hold within an unknown context.

I call it copy-paste reasoning.


“You shouldn’t do fixed price, fixed scope contracts, because…”
Fine, but that doesn’t help me if that’s the only thing my biggest customer wants.

“Big up-front requirements are wrong, because…”
I know, but my customer just handed me a 200 page requirements study and he pays me to implement it.

Teams must be cross-functional, with all roles represented in the team, because…”
Sure, but the customer contracted another party for front-end design, on the other side of the country.

“You have to do iterations of four weeks each, because…”
Right, but that doesn’t help me much if my project only lasts for three weeks, does it?

“You’re wrong when your people carry out evaluations with on-line forms, because…”
Wow, are you psychic? Are you able to understand our people from the other side of the ocean?

I appreciate any kind of advice from any source, including advice that doesn’t translate well to our context. It is an opportunity to learn and to understand how our situation compares to, and differs from, the world outside.

Context Matters
However, best practices are always context-dependent. You cannot tell someone else what to do, without understanding their context. Even if you’re 95% right, people will only be digging their heels deeper when you don’t acknowledge that their situation is slightly different.

So, I advise you not to apply Copy-Paste reasoning.

Use only apply Copy-Paste Special… and carefully select your options.

Scaling agile success

I recently had someone pose a question to me that got me thinking about the scalability of agile success. Here was the question: “I’m part of large organization of over 1,000 people. Our small team of 40 has been using agile with a great deal of success. Now our company wants to me to extrapolate the successes we’ve enjoyed from agile (efficiency, value, profitability) to the rest of the company. Do you think the agile success of 40 people can be extrapolated to over 1,000 people?”

It’s a great question and I don’t think there is an easy answer to it. Speaking from my own personal experience, it’s been difficult extrapolating the success our small team of five developers had in the past to our larger organization of about 35 people. There are many challenges as you scale agile up. Agile practices depend heavily on collocated teams that are cross-functional in nature. When you start scaling agile up, you need to consider geographic dispersion of much larger project teams that may not be as cross-functional as you’d like them to be. This is just the nature of large organizations. This can have an impact on communications and coordination of work across dispersed teams. Another success factor that’s related to this in larger organizations is the use of matrix management. Teams in large organizations are usually composed of a mélange of team members who, because of matrix management, report to and are managed by different parts of the organization. This can lead to the fire drill mentality and “resource ownership” issues. This can quickly degrade the level of commitment and the quality/value of functionality that the teams deliver.

Other obvious factors that can be relevant when scaling up are the development and testing environments. Teams need to be able to continuously integrate their work and have a common infrastructure that supports this across a large organization. Teams need to know quickly whether or not the work they’ve done is negatively impacting the rest of the codebase. This is no small matter and can really improve or decrease the effectiveness and efficiency of agile development teams.

There are probably many more factors that are related to scaling agile up, but to me, the ones mentioned above seem critical. Personally I don’t think you can simply extrapolate the success of smaller agile adoptions to larger organization-wide adoptions. I think that each has its own distinct set of challenges that make it difficult to draw a line and say we had X amount of success here, so that means we’ll have 10X success when we scale this up. However, that is not to say that large organizations cannot enjoy the benefits and successes agile practices offer. They just have to approach it with a different mindset than smaller teams or organizations. In fact, many large organizations have really recognized tremendous gains using agile practices. If you’re interested, there is a great case study available about BMC Software adopting and scaling agile practices throughout a very large organization. It’s available here. It’s well worth the read and gives some great insights into how large companies adapt to make agile work for them.

Agile adoption: Why isn’t this stuff working?

image Lately I’ve been hearing feedback from lots of different people that they’ve “adopted” agile and it’s just not working for them. This always causes me to pause, step back and ask a few questions. Here’s the list that usually runs through my head: How did your company adopt agile: top down mandate or grown organically? Was your adoption done in stealth mode or full fledged “Hello world, we’re going agile”? Do you have real executive support for your agile adoption? What kind of projects have you implemented agile on: fixed price, fixed scope, fixed schedule? Has your staff received any kind of agile training? How many projects have you run in an agile manner? How long ago did you start doing agile?

I run through these questions because I think each one represents a potential failure point for agile adoptions. Let’s take a look at each one.

  1. How did your company adopt agile: top down mandate or grown organically? This is really important. In the teams I’ve talked to and worked with, it always seemed that agile was adopted better when it was grown organically not when it was mandated. The mandate approach assumes command and control and never leads anywhere good. People need to want to do agile. So how do you get people to want to do agile? Show them small successes. Let a single team or a few small teams start doing agile. Then, as they show successes and learn some of the lessons, other teams pick up on it and want to do the same. The teams that went first, help the teams that followed adopt agile and they pass on the lessons they’ve learned. In other words, you can’t just throw the agile switch and voila…everything is good. Mandated adoptions often fail because there is no magic switch. People resist change when it’s mandated. They embrace it much better when it’s grown out of proven success.
  2. Was your adoption done in stealth mode or full fledged “Hello world, we’re going agile”? The CEO or COO stands up and proudly announces “Hello world, we’re going agile” and then thinks in the back of his mind “I hope this voodoo works”. And, because there was such a public announcement of the company’s intent, there is extreme pressure to “make it work”. This pressure leads again to command and control thinking of “make this stuff work” or we’re going to be embarrassed. On the flip side, if you start in stealth mode, you work projects internally using agile practices but say nothing of it until the project is over. When you client asks “How were you able to deliver value in a timely manner?” you can answer “With agile practices”. Because there is no external pressure to live up to some expectation, stealth agile teams have an internal commitment to making agile work for their own good without being forced to do so to meet some external expectation. Once they gain the successes on stealth projects, they’ll be more comfortable with announcing that they develop in an agile manner to the world.
  3. Do you have real executive support for your agile adoption? Lot’s of executives have “heard” about agile and want to do it because everyone else is. But, they don’t really understand the level and type of commitment an organization must make to truly adopt agile. If you haven’t already noticed, one of the key things an organization needs to let go of when they adopt agile is the command and control structure. It’s a very hard hard thing for most executives to let go of, and many never fully commit to and support a more servant leader approach to management. Failure in agile adoptions occur when lip service is paid to “supporting” agile practices, but business goes on as usual: The command and control structure remains, long winded requirements documents are requested to support the inevitable scope disagreements we’ll have with our clients, deliverables-based contracts and project tracking remain, and percent complete and earned revenue calculations are the only important project metrics. If organizations can’t come around to supporting agile practices and drop their old “bad” management habits, agile adoptions are doomed to failure.
  4. What kind of projects have you implemented agile on: fixed price, fixed scope, fixed schedule? If you’re going to adopt agile, you need to consider the types of projects you’re going to run agile on. That means thinking about contracting in a whole new light. If you’re trying to use agile practices on a fixed scope project, expect to fail outright. Fixed scope is the antithesis if agility. If you’re running on a fixed-price project, better chance of success, but only if scope is not fixed. Fix your price and your scope: FAIL. And fixed-schedule, another bad option. So, if you’re trying out agile on a project that has not truly been contracted to run agile, expect failure. The answer is to work with your clients to educate them and develop agile contracts that both you and them can work with and live with.
  5. Has your staff received any kind of agile training? “OK, so we’re going agile. Here’s the 2-hour overview. Go out and be agile!”. One month later: Fail. Why? Agile is not easy. It sounds easy and can be explained quickly. But, there are many subtleties and nuances to agile. For teams to really grock the whole agile thing, you need to invest some time and money for training. An agile team needs to learn how to plan in a whole new way, how to develop user stories, how to develop tasks, how to assess themselves and their practices. And, they need to learn about the heart of agile: commitment. Unless teams deeply understand what makes agile tick, they’re going to have a difficult time being successful at it. A two-hour “Welcome to Agile” powerpoint ain’t gonna do the trick. Sending teams to something like scrum master training is well worth the time and money you’ll spend on it.
  6. How many projects have you run in an agile manner and how long ago did you start doing agile? My advice here: give it room to breath. It takes a few turns around the block to get agile running smoothly. Teams need time to gel, get to understand agile and learn about themselves (see recent post on this topic). Like I said before, there is no magic agile switch. It takes time for agile teams to become successful. The more time you allow itto run, the more likely it will be successful in the long run. Too many teams hit the first agile bumps and hurdles and instead of trying to learn from them, they pull the plug and declare their adoption of agile a failure. There are many stages an agile adoption goes through and some can be painful from many points of view. Slow down, take a deep breath, and keep trying.

So, what should you do if your agile adoption is “failing”? Here’s a hint: Agile is HARD. Ask yourself some of the questions above and see what might be causing the failure. I believe that too many organizations only half-heartedly adopt agile and pull the plug far too early before it has a chance to prove itself. Give agile a try, give it some time, and think hard about the six questions posed above before you pass judgement on your agile adoption.

Short term teams

One of the key benefits of agile and Scrum is the growth and maturing of the teams that work together. The longer a team works together, the more it learns about itself and its members. The team learns what works well for them and what doesn’t and they use this information to adapt their practices. This learning is central to the continuous improvement of practices that drive the engine of great agile teams.

However, a problem exists in many organizations (especially consulting organizations) that may denigrate the effectiveness of this core agile practice. I’m talking about short duration development teams. If you’ve worked in the consulting world, you’ve been there before. Teams are assembled in a mix-n-match fashion to tackle specific contract jobs. Many of these jobs are short term, just a few months in duration. Then, the team is disassembled, put back into the “resource pool” and reassigned to other jobs with new teams. Sometimes teams get to hang together on the next job, but many times, they are separated and placed on new teams with new team members. The problem I see with this is that these teams don’t work together long enough to really learn about what’s working and what’s not. They don’t gain the benefit of working agile and finding ways to improve their practices. I think that in addition to not gaining the valuable learning experiences, shorter term teams don’t have the chance to really gel as a team. By the time they become familiar enough with each other and build an good level of trust and loyalty to really make strides in improving their practices, they’re torn apart and reassigned.

My preference would be to see teams work together as cohesive units for long periods of time. This allows the team time to grow and mature together. It builds trust and loyalty within the team that leads to a team’s commitment to building the best products and developing the best practices they can as a team. These teams have the time to do some real learning and real improvement. Our team here in Ft. Collins has worked both ways and I’d have to say, we’ve made much greater advances when we worked together as a team for longer durations than when we’ve been split up amongst several smaller teams for short term projects.

Product Manager and Scrum Product Owner

Last week I managed to take part in a widely recognized product management course (special thanks to my line manager Mika Hoikkala who found it useful for the company to finance my long-haul trip). I am coming from the engineering/Agile world and one of the main points for me was to figure out what my new role was really about, whether it is more, less or equal to Scrum Product Owner (PO). The course was useful in this regard and here are my findings.

The course wasn’t linked to any particular methodology, but whenever the methodology was relevant, agile methods were deemed as more effective. Still the parallels with Scrum in this post are my personal opinion, rather than what has been taught on the course.

Product Manager

Product Manager is a role to care about not even a product itself, but about particular problems of the market or market segment. It includes tactical activities, such as doing presentations and strategic activities, such as market research and competitive analysis; technical activities such as figuring out the release milestones and not so technical activities such as product positioning. Product Manager is a role linking sales, marketing and development, a role supposed to stand strongly in the what domain, hunt for facts and stay out of the how part as much as possible.

Product Owner

Product Owner is a specific role of the Scrum process. Product owner is supposed to be ultimately responsible for the success of the product and its return on investment. In order to fulfill these responsibilities, PO is supposed to communicate a clear product vision, supply his requirements in a form of a strictly prioritized list and ideally stay in the daily contact with the team clarifying the requirements as development team starts working on them. PO is also expected to stand strongly in the what domain and stay out of the how part as much as possible. How PO is supposed to figure out the market needs and where he finds time to do market research, communicate with the team and defend the project in the higher management forums is beyond the process.

Merging roles

If your company is solving not THAT complex problems, you know your market or a single customer well, than a single individual can indeed perform both the Product Manager and Product Owner roles. A more realistic solution for many cases could be to assist Product Manager, when it comes to the lower level technical details. The forms of assistance could be different.

A mature agile team with an experienced Scrum Master might be self-managing, self-accountable, self-sufficient and self-responsible enough to proactively help with creating the efficient product backlog and could figure out how to nail the low level details on its own. For example, a User Experience Designer on the team could be a good candidate for deciding on the report dialog capabilities after Product Manager clarified the underlying problem well enough.

With the less experienced team or when Product Manager is more busy with the customer/sales/marketing you might need to get a Scrum-proficient proxy-PO to care about formulating Product Backlog, grooming it and being with the team on a daily basis.

Your experience

How does it happen in your organization? How do your Product Managers participate in the process?

Derek Morrison dropped a couple of links to his experience on making Product Management work with Scrum. You might find it worth looking at.

Picture courtesy of eflon @ flickr

Ask and Thou Shall Receive

Bible A Google search on the text “Ask and Thou Shall Receive” got me a few different references to Bible chapters, including Matthew 7:6-8, Luke 11:9-10 and John 16:24. It seems that the disciples were never shy of asking when they wanted something, and I cannot blame them.

Asking people for things you want really works!

Children Asking
There’s a saying in my language (Dutch): “Wie vraagt wordt overgeslagen.” It roughly translates to “Those who ask will be skipped“. It is often used to get children te keep quiet when they’re asking for sweets or presents. But my grandmother, a religious person herself, has fought against this idea. Several times she said to us: “Children that never ask, will not get what they want.” She actually might have been referring to “Ask and Thou Shall Receive“, either consciously or not.

LinkedIn Recommendations
This week, when checking my LinkedIn profile, I realized to my horror that I still had no recommendations from any of my 145 connections. How could that be? Why had my friends and relations never taken the time to write a small endorsement for me? My work cannot possibly be that bad, can it? My confidence and self-esteem were in a shambles. Fortunately, remembering my grandmother, I knew the answer had to be very simple…

I had never asked!

So I kindly asked a portion of my contacts to write me a recommendation. No obligations, no strings attached. And only if they really meant it. Within an hour I received my first glowing reviews, and a couple of days later the counter stands at a respectable 14 recommendations. More than I had hoped for! My self-esteem was able to recover quickly. And, in my turn, I recommended my granny in a thank-you prayer.

Successful, hard-working, agile people are busy and they have lots of things requiring their attention. Therefore we sometimes forget that our co-workers, friends and relations are quite willing to help us out, or do us a little favor. You shouldn’t keep struggling silently with some problem, hoping that someone will finally notice that you could need a helping hand. You have to tell your team what you need. You have to ask, or you will never get what you want. Ask and Thou Shall Receive!

Having rediscovered the virtue of asking, I would like to ask you to check out my personal blog at www.noop.nl. It’s about managing software development, including topics like complexity, agility, quality and other subjects of a less biblical nature. It’s almost as good as this site, only different! 🙂

Agile Job Descriptions

Jobdescription I’m in the process of reorganizing and streamlining job descriptions in our company, and now the HR manager wants me to define the differences between a junior software developer, a medior software developer and a senior software developer. Ehm… ok, that’s a tough one. My first thought was that juniors need coaching, senior don’t, and mediors end up somewhere in the middle. I would be perfectly happy with such a fuzzy-logic definition, but I’m afraid both our HR manager and our employees want more tangible function profiles.

Oh boy…

The Problem with Competences
The easy solution is to use competences. I could write job descriptions formalizing that seniors should be able to do A, B, and C, that mediors are able to do A and B, and that juniors are only expected to do A. But then I would be painting myself into a corner. I’m quite sure that, soon after formalizing such competence-oriented definitions, our software developers will need to acquire the new competences E, F and G. What then? I might be stuck with people not willing to adapt to the new situation, because the new competences haven’t been formally documented. And continuously changing formal documents is the last thing I want. Not in the least because, in a country like The Netherlands, any change in a formal document needs the approval of at least three committees, two management layers and one counsel of wise old men.

Using Agile Requirements
Creating job descriptions is like setting up requirements, and I am gonna try and do this the agile way. I am unable to predict the future, therefore I am unable to define what competences people need to acquire three months from now. It’s something we simply have to discover along the way.

Therefore, I think I might define our new job descriptions along the following lines:

  1. Be able to satisfy project stakeholders, among customers and colleagues.
  2. Be able to deliver projects that are profitable, and matching their quality criteria.
  3. Be able to learn, follow and adapt professional software development processes.

Each of these requirements can be measurable (well, more or less), and they can be tuned to fit the different levels of juniors, mediors and seniors. For example: juniors must be able to learn processes, but seniors should be able to introduce and adapt them. But most important, they allow for any kind of changes in processes, technologies, quality criteria and stakeholder requirements. And with an ever-changing environment, that’s exactly what I want.

The Single Best Source Control Model

VersioncontrolIt doesn’t happen often that I keep silent about anything. Whatever the subject, my opinion is usually formed before I have finished thinking about it. However, with source control techniques, this is apparently not the case.

Two Great Articles
I know two very good articles on source control that every software developer on the planet should read. OK, I admit that is an opinion. But once you’ve read them, I’m sure you will understand why I feel that way.

Version Control for Multiple Agile Teams (Henrik Kniberg)

The Importance of Branching Models (PDF) (Chuck Walrad, Darrel Strom)

Both articles agree that there are good and bad ways to organize version control of your code. Both offer more-or-less the same advice on what the best branching model is, and I couldn’t find any flaw in their reasoning. I had nothing to disagree with. (And that’s a rare experience to me.)

For agile software development, a good version control model is essential!

Agile team need to be able to release software at any time, while working on new iterations, and (possibly) sorting out a few bugs from the previous one. The branching model promoted by these two articles takes care of that, and much more.

I am actually surprised that source control isn’t covered in the books on agile development methods. But then again, maybe this is the only subject on which Schwaber, Beck, Cockburn, Poppendieck and De Luca all agree as well.

The case for collocation

image I’ve been thinking a lot about the collocation of agile development teams (or any development team for that matter). Some people argue that collocated team members are essential to successful software development while others argue that it doesn’t make any difference. The more I think about it, and the more we operate with geographically dispersed teams, the more I’m starting to believe that collocation matters.

Currently, our team is spread out between Ft. Collins, CO, and Orlando and Jacksonville, FL. While things have not gone terribly wrong having dispersed team members, I have noticed a difference in communications. The difference is that in the Ft. Collins office (and I’m sure in Orlando and Jacksonville), there is a lot of informal communication that occurs amongst collocated team members. You know, the kind of discussions that happen spontaneously. When these happen, a lot of project information gets passed between team members that doesn’t get transmitted to other remote team members. There is no malicious intent to not communicate. It’s just that the impromptu discussions don’t usually inspire anyone to dial in to a teleconference number and all that…precisely because they are impromptu.

On the flip side, the scheduled daily stand ups, planning meetings and reviews all happen when they’re supposed to and everyone communicates on those calls. However, I have found that something is lacking on those calls as well. When a team is all together in a room, there is definitely a different dynamic than when there are “voices” on the phone. Body language plays a huge role in communications and tells a lot more than than what people are saying. However, what I find really absent is the sense of team and camaraderie that exists in a collocated team. There are many “physical” exercises that we used to do for planning meetings and retrospectives that have been lost due to collocation. I found those really useful and without them, I think our planning and retrospectives are less effective than they could be. Maybe we just need to adapt those exercises to be more amenable to the space between our team members.

All in all though, I think I would definitely be in the camp of folks who believe that collocation really does matter. It build a better sense of team, increases both verbal and non-verbal communications, and really fosters a more collaborative work environment.