Tag Archives: agile coach

Whatever Happened To Software Engineering?

map-clip-artI’ve been working some on my mailing list to help Agile teams do better and one of the recurring topics from readers has been how to fit “normal” software engineering principles into an Agile framework. How can you do database design, for instance, if every 2 weeks the database is actually being used?

Of course there’s an easy answer: we incrementally do things in Agile. So, for instance, you might use all those database design skills, but a little at a time, instead of all at once. The first sprint you sketch out the tables, maybe add a few fields. Second sprint you change up the tables some, add some more fields. Third sprint you’re working a bit with cardinality. And so on. The concept is that we do the same stuff, only a bit at a time instead of becoming a bottleneck.

This is a good enough answer, and it works for most stuff. But I think it’s also masking a conflict that many people have: software is supposed to be engineering, not just little dips and drabs of stuff added in here or there. To hear many YAGNI pundits and others, you don’t actually do anything until the last minute, and then only in support of the exact thing you’re working on. Most engineering disciplines, however, encourage you to solve the entire problem. If you’re building a bridge, architect the bridge first, dang it. If you’re going to the moon, you’d better have some technical work around the entire trip. You don’t just launch into orbit and figure it out from there. Building incrementally is fine. But there exists fields of inquiry where there’s a long sequential process of refinement over the entire problem domain — one in which you gain execution advantages by working the entire problem at once. We seem to either have tossed this fact away or are purposefully ignoring it.

I began noticing a problem. When we talk about these things, people shut down. I suspect many folks in software engineering, especially Agile coaching, don’t have an engineering background! This can lead to a severe disadvantage when dealing with certain areas:

  • Modeling I don’t see many teams sketch, much less model. That’s a shame, because visual information is a much more effective way to discuss technical matters. Add in a bit of formal training, say 30 minutes, and teams can sketch in UML. Then you can link diagrams. There’s something to be said for lightly sketching problems on the whiteboard. Take a picture if you want to keep it. Start using a modeling tool if you realize that you’re having a group discussion around highly technical stuff. You can sketch, you can use UML, you can use a modeling tool, all without having to become a waterfall BDUF project. Really, you can. It’s the only way to go for complex projects.

  • Process Analysis Does anybody remember structured process analysis? Not to see most teams. The way most people teach Scrum and Agile is that a list of stuff appears — I guess from the sky, brought down by a dove to the Product Owner. The team only works on the stuff in front of it. Don’t spend a minute thinking about the big picture! After all, your project could end at any point in time, and you don’t want to spend one minute on things that you’ll never need.

    Of course, there ARE projects that could end at any moment, but for most of us, we’re brought on to address some kind of system: a website, a business problem, an internal need, and so on. The team, and project, has some cohesion. You’re going to be here in six months, and you’re going to be working on the same thing. For those kinds of projects, spending some time doing process analysis is a no-brainer. You get back much more than you put in. I’m not talking about anything waterfall-like. I’m simply talking about building a process model, over time, of who does what with the system and why. This can help you cut to the chase and decide which stories should be prioritized first. It can help you define and have a common understanding of your stories. It can help the Product Owner make economic decisions about the backlog, and it can help the team interject creativity into the solution, instead of just being a bunch of order-takers. Great stuff for couple hours or so each sprint.

  • Lean Startup Another one of those end-to-end, outside-the-team areas where the team and the Product Owner need to work. What hypotheses is this work supposed to be testing? What are the revenue streams? How are we addressing the gap between market and PO? In a startup world, all these things are critical — and there’s a sequential engineering-type endeavor that can take you from point A to point B. It’s a mistake not to do it.

When we teach things like good architecture or proper database design, many times we view the developer as the center of the universe and the engineering practice as something that’s completed in toto before any other work can occur. This has caused tremendous pushback from Agile teams, rightly so, because it creates handoffs, bottnecks, and unecessary documentation. But are we overreacting the other way? Isn’t there a place for long-format, sequential, detail-oriented work, even in Agile teams in complex domains? Especially in Agile teams dealing in complex domains?

Each of these has a few areas in common: 1) they’re about more than the work directly in font of the team, 2) they’re about having the experts, the team, assist the organization in its work, 3) they’re sequential, 4) they build on themselves as work gets done, 5) they’re not the work itself, and 6) they end up discovering things for the PO and the organization that wouldn’t be discovered otherwise. Because of these attributes, they tend to “fall between the cracks” when teams adopt Agile practices. They are traditionally part of what people employ engineers to do.

How about you? Are there engineering processes you miss seeing in your Agile teams? What are you doing to make up for it?

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

3 minutes, 3 days, 3 weeks, 3 months, 3 years

With everybody talking about Marissa Mayer and how much she might change at Yahoo, perhaps it’s time to look at some fundamentals. If you want to have an influence on an organization, here are the critical numbers you need to know.

In the first 3 minutes — most likely inside of the first 3 seconds — people will be making judgments of you that will be difficult if not impossible to overcome. Things like social signalling, body language, dialect, relaxation, fitness, odor, race, clothing, and NLP play a critical role here. These things shouldn’t matter. People should only judge you by what’s inside, not what’s outside. The problem is that our brains have evolved in exactly the opposite direction from where our morals have. We instinctively make snap judgments, and they become difficult to change later. That’s just the way it is.

It takes about 3 days of people observing and working with you for you to pass the “smoke test” in organizational change. They are able to somewhat answer the questions “Is this person a lunatic?”, “Can this person be trusted to work alone with important people?”, and “What drives this person?” From here people can begin gossiping about what type of person you are and whether or not you’ll add to the problems or help with the solution.

The 3 week milestone is critical to determining how much traction you are likely to get doing your job. It takes around 3 weeks of meeting lots of people and diving deep into their work for you to figure out what the organization’s real cultural issues are. You can even try a couple of ideas to see what kinds of things fly with them. By three weeks you have a great idea of how far you’ll be able to take folks.

At 3 months, the honeymoon is up. Like milk, outsiders and consultants have a shelf-life, and around 3 months you are becoming more one of the gang instead of an agent for change. (You can still remain an advocate, though). If you’re kicking ass, you can start moving up the ladder or across organizational groups to begin working in a new arena. While there’s still a lot of good you can provide, you will be providing it as a team member, not as a consultant. Note that 3 months is a rough estimate. You might run as long as 6 months in your honeymoon phase.

This is a good time to disengage. If you’re able to help in another area, that’s an option. Or you can hand-off what you’re doing to a fresh set of eyeballs while you coordinate remotely. But a professional realizes that it’s around this time to be either up or out. Once you pass this point, people begin figuring out how to channel your energies in ways to suit them, the organization begins changing you more than you are changing it.

By three years, you are simply another employee. For many, this may be exactly what you want: a steady paycheck and job security. It can be a great and rewarding life, but you are no longer the guy brought in to change things. At 3 years, you are indistinguishable from those you are helping.

Of course, there are counter-strategies. Executives bring teams with them. They rotate senior staff. They limit and control exposure to key personnel to maximize impact. But that’s a longer discussion outside the scope of what most of us might face.

Helping groups change is one of the most rewarding things you can do in life. But whether you’re an outsider just passing through or somebody settling in for the long-haul, you have to understand and play the numbers.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Coaching Coaching Teams

If you work IT long enough, you go meta. That is, at some point you’re not doing the thing, you’re doing the thing about the thing.

Here’s an example I shared with my audience today about what happens when you coach teams that coach.

Many times, the coaching team is brought in under a Statement of Work, or SOW. The whole purpose of a SOW is to describe exactly what the team will be doing. And most every time you will have a contact that will prioritize work and define “done”. So you have a backlog, a budget, a Product Owner, and a highly-skilled team (after all, this is a coaching team — these guys know what the heck they’re doing!) What could go wrong?

I think people think that having a great team means having really smart people work on a clear list of things with somebody telling them when they’re “done enough” is all they need — but that’s not true. For instance, lots of startups who are funded by VCs do a lot of activity and yet get nothing done. Activity does not equal progress! You can have structural problems with your list of things to do that can’t be overcome by any degree of technology or smarts.

Activity does not equal value.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Agile Coach: Balancing Knowledge and Practice

In theory, practice and theory are the same. In practice they aren’t. — Yogi Berra

There are two kinds of teams and developers in the world: those that are heavily into knowledge and those that are heavily into practice. Both lead to poor performance.

The first kind has read all of the books. Perhaps they’ve attended some seminars or conferences. They’re excited about various ideas they’ve heard and want to try them out. Discussions about how practical something might be are regarded as counter-productive, or foot-dragging. These teams are knowledge-heavy. Outsiders really admire how smart these people are, but secretly are afraid of letting them around sharp objects, i.e., they don’t really trust them.

The second kind isn’t much into book-reading. They’re just there to execute — to deliver something. They’re focused on the end-results and getting there as quickly as possible. Discussions around new ways of doing things are regarded as frivolous. These teams are practice-heavy. Outsiders are really excited over all the results these people get, but secretly are afraid that the mess and compromises that are being made that are going to cause a lot of problems later, i.e., they don’t really trust them.

So — how to balance knowledge and practice? I apply these principles in order:

Continue reading

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

What’s Your Work Area Look Like? (Agile Coach Version)

I’m finishing up working for a large client next week, and I’m also playing around with the new SnagIt version screen capture widget, so I thought it would be neat to combine the two together and capture what my current work area looks like.

Note: you need Flash to be able to see this correctly.

Since this is my first shot at this, if you’re having problems with the display please let me know. Hey — works fine on my machine.

So what’s your workspace look like?

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Agile Coach Code of Conduct

A while back I started on an Agile Coach Code of Conduct. I noticed that after coaching for a while I started to forget basic principles that should be part of every coaching engagement.

So I put this list together to help me (and others) remember what coaching is all about.

Like everything in agile, it’s an ideal, not something you can ever perfectly do.

Continue reading

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.