The Right People

An Agile project needs good people. But what makes good people for an Agile project? They need skill in the work at hand, of course. But you need more than just skills. There are some other competencies that are critical to helping an Agile team work well. Here’s a short list of key competencies.

Courage – Agile developers need to have the courage it takes to try things. They also need to have the courage to commit. Both of these imply the courage to make mistakes and to admit them openly. Without courage your team will be too tentative. They will tend to over-estimate effort (whether you’re using Story Points or something else). They’ll be afraid to set a target and work toward completing it. Worst of all, they will make excuses rather than face up to their problem areas. Courage to face your weaknesses gives you the opportunity to improve or help the team compensate. If a team member makes excuses rather than addressing their weaknesses they eventually have to leave the team. (Of course, you need to give them room to be courageous. But that’s the subject of another post.)

Transparency – This goes along with courage. Agile developers need to be willing to share exactly what’s going on, the good and the bad, in the work they’re doing. They need to be quick to ask questions and ask for help. They need to share their blockers so the team can work to unblock them. It’s can be frightening to be so transparent, especially if your experience is punishing bad news. People will try to hide the bad and hope for the best. That kind of delay in admitting a problem makes dealing with it all the harder. An Agile team needs to deal with the truth if it’s going to succeed.

Ownership – Your team members need to feel that team success is their success. You don’t want people who are complacent about delays or problems with their work. And you really don’t want people who don’t accept responsibility for how the team is doing. Obviously, things happen that team members can’t be responsible for, but team members need to take enough pride in their work to want to produce good results on time. You want people who will find ways to meet their commitments, not shrug when they miss them. Team members need to own their targets and do what they can to achieve them.

Ability to Plan – Many people think Agile methods don’t require planning. But nothing is accomplished without a careful look at how it can get done. Agile team members need to be able to break their work into steps and create a plan for accomplishing them. Having a plan allows the team to assess how it’s being executed. The more granular the plan the more effective the team will be at spotting or even avoiding potential problems. A good Agile team member can make and work a plan, and make noise when the plan runs into trouble.

These are some of the competencies, beyond skill in the role, that an Agile team member must possess. If you’re just focused on skilled people, you’re not going to succeed with your Agile team.

Advertisements
Posted in Management | Tagged , , , , | Leave a comment

An Agile Firm Fixed-Price Contract

On February 1, 2017, I started as the Scrum Master on a Firm Fixed Price contract. We had a specific Scope of Work and a target end date. The planning team had reviewed the Scope and assessed the number of Scrum Teams we would need to complete the scope on or about January 7, 2018.

It’s now December of 2017 and we are on track to complete the project when we said we would while staying within our budget. We have already released some of the highest quality software I’ve had the pleasure of overseeing. The project goal is moving systems from a mainframe computer to a modern n-tier application. The end-users will have to get used to the new interface, but we all believe they will appreciate how much easier their jobs will be after they learn the new interface.

While leading this project I’ve learned some very important lessons.Over time I’m going to be sharing these lessons. Some are no brainers, although it’s been nice to have them reinforced. Some surprised me. I’ve learned lessons about people, agility, the customer, scope, quality, and tools. I’ll be sharing on all of these topics.

I’m still convinced that Scrum is the process that any organization should use to manage software development, and probably the rest of its projects. But Scrum is a framework that’s designed to flex to fit the needs of individual teams and specific projects. I’m not going to recommend a specific way to run Scrum. But I will tell you where and why we made adjustments, and I’ll share what I liked and what I didn’t about the choices we made.

All that I’ve learned will help me do a better job as I help more organizations embrace Agile and Scrum. I hope you’ll read along and share your own experiences.

Posted in Success | Tagged , , , , , | Leave a comment

Working in Sprint time

Three separate teams are all working on pieces of the same project at the same time. They’re working with micro-services in individual containers so the teams can develop independently of each other except when there are true dependencies.

Why do I still hear people complaining that their stack of containers just broke? Each individual manages his or her stack, so why can’t they work with a stable set of containers except the one they’re developing on?

It seems the reason is we’re all in a hurry because we have to finish something every Sprint. We rush to accept un-proven containers so we won’t fall behind, and fall behind as a result.

I’m going to give you the punch to this post right up front. If you’re cutting corners on good practices to get things done, you’re doing it wrong.

It doesn’t matter what your particular issue is. For some it’s merging code directly into the release branch without testing. With others it’s not completing the unit tests. Still others don’t have time to document what they’ve built (to the level of documentation agreed by the team.) Too many of our people are convinced they don’t have time to finish the work. They can’t wait, the feature is too important, this is a small change, I have to get this bug fix to QA, the list of excuses is long. The list of problems caused by rushing is longer.

There’s a reason Scrum asks a team to define its Definition of Done. It’s so these issues don’t become questions. Unit testing completed, documentation written, code reviewed, these are all things a team can agree on up-front. Once agreed, team members should work on their Stories until they’re done, not cut corners to turn in their work quicker. If they don’t finish, it’s not finished and the bill will come due at a much more expensive time.

As much as it feels backward, if you really want to get a lot of work done in your Sprints slow down and make sure you finish everything you start according to your definition of done. There’s no better way to keep up at Sprint speed than to pick up a Story, finish it, and put it down. If you try to juggle Stories, writing code for several then writing unit tests for several, you’ll only slow yourself down. And if you talk your team into accepting the Stories because they’re functionally complete, you’ll pay a serious penalty later. You may have every intention of completing those unit tests, but you won’t. Once you start letting new functionality trump unit tests, you’ll never stop.

So, if you want to work at Sprint speed, pick up a Story, FINISH IT, and put it down. If you don’t, you’ll lose it later when you’re solving the problems you left behind.

Posted in Development | Tagged , , , , | Leave a comment

Priorities

One of the keys of Agile is Business Value. Everything is about Business Value. If you’re working on something you should be asking yourself, “Will this produce Business Value?” And, to the extent you can know, “Will the Business Value be worth the effort?”

So, if there’s a business need to get a new widget on the main screen that will link you to a new function, for example, you can be asking, “Will users actually use this function? Is it an important enough function that the trigger needs to be on the main screen? Can it be in a menu or in a subordinate screen? How do I turn this into high Business Value?” Then there are the ancillary questions such as, “Is it less valuable if I delay? Would it be more valuable if I built it sub-optimally now and got it out to our users and then optimized it later?” These are all good questions and they help us focus on the most meaningful tasks to the bottom line (which is the company or project making enough money to keep us employed).

But there are some thorny questions that we sometimes forget to ask, generally because we’re optimists and we assume things are going to go well. Here’s a big one. What’s the business value of adding a validation to a field? In a happy path scenario there’s none. But an old QA rule is that anything a user can do some user eventually will do.

I recently built an application that didn’t validate the user entered a first and last name. There was no use case for either name being empty. But, sure enough, someone came up with a reason to enter a record with no first or last name. The last name didn’t actually cause a problem (although it would have made the information useless). The first name created a disaster.

Fortunately for me, it wasn’t a disaster in an important application like user banking. Still, it was embarrassing. Because I was so focused on creating additional features with Business Value, I never put in code to ensure first and last names would be entered. (And I really should know better.)

At a higher level, what’s the Business Value of a good unit testing framework that can report to your continuous integration tool? If you don’t have a problem with regression bugs there’s not much. But does that scenario actually apply to you? What’s the Business Value of putting lots of logs into your application and making sure you have good log management tools? That depends on how badly your system crashes when it’s in production. (I can say I had logged things correctly so I found my blank name bug very quickly, but it’s still embarrassing.)

Make sure you understand the Business Value of these infrastructure issues. If you don’t prioritize them properly their absence could create a high negative Business Value. Rushing features into production without considering these is an invitation to disaster.

Posted in Quality Assurance | Tagged , , , , , , | Leave a comment

Not Planning is a Bad Plan

Sprint x-1 ends and it’s time for Sprint x to begin.

Our teams meet and accept the Stories for their Sprints. Acceptance is based on initial Story Points and whether the priorities make sense. After that, the teams get together and actually map out the tasks necessary to complete each Story.

Except day 2 comes around and I don’t see the tasks. I ask, and the team didn’t take the time to plan, they just started working. They don’t want to take the time to create the plan. They know what they need to do. They’d rather not waste the time writing that down.

What could be wrong with that?

From a managerial point of view, nothing is wrong. We’ve moved away from Command and Control based management so managers don’t need to see detailed plans. When the Sprint is done any management functionality can work off the completed Story Points and the current velocity.

But some of the Management functionality is taken by the team itself. It has made a commitment. If it wants to keep its commitment it has to understand how it’s doing. Otherwise the last day of the Sprint is here and they’re not ready.

Really good developers who are correct when they say “we know what we  need to do” fall into this trap. It’s not a skill issue, it’s a human nature issue. There are lots of scenarios that will get you to this point, but if you don’t have a written plan you can refer to before you start working each day you will go off plan. (NOTE: You have to use it, too.) Only the most trivial Stories don’t fit this pattern.

So, take the extra time. Put your plan down. Make sure your team can follow it. The time you spend at the beginning may save you twice as much at the end.

Posted in Uncategorized | Leave a comment

Skinned Knees and Broken Bones

How do people learn? I know there’s an entire field of study about this but my own experience tells me people learn from experience. Fortunately or unfortunately, the most instructive form of experience is making mistakes. Or maybe mistakes just stick with us better?

As a ScrumMaster I’m supposed to support self-organizing teams. While the definition of “self-organizing” varies, one key aspect of Scrum is the Retrospective. In a Retrospective, a team reviews its own performance and recommends its own improvements. I fully support this model, but sometimes my experience tells me a team proposal isn’t a good idea. This gives me a choice. Do I allow the team to make the decision so it will have buy-in, or do I draw on my experience to overrule a bad idea?

For me, the answer comes down to skinned knees and broken bones.

When teaching your children to ride a bicycle, you have to decide when to let them ride on their own. Your biggest concern is the likelihood of serious harm if they fail. As they grow and take on other activities you continue to assess the likelihood of serious harm if they fail. We accept that our children will get skinned knees. What we try to avoid is broken bones (or worse). So this is my metaphor for when to let the team try a solution and when I step in on the basis of my experience.

Will failure lead to skinned knees or broken bones?

Recently we had to split our team to allow a group to start working on the proofs of concept (POC) for the next generation of our software while the remaining team members continued to support the existing product. Our support lead did not have the significant architectural experience, but we wanted to know if the support lead had the ability to grow from a task-driven member to a problem-owning member. Was it OK to let someone with this lack of experience take responsibility for determining the correct bug fixes in our existing product?

If this person failed, would we skin knees or break bones?

We decided we would skin knees and we moved forward. The support lead made some mistakes, but we only skinned our knees. And together we learned a great deal about where this support lead still needed to grow – a lesson we all believed was worth the pain.

So I offer this metaphor to you. Will you skin knees or break bones? I’ve known some extreme-sports types who would say, “It depends on how bad a break,” so adapt the model for your style and team. Whatever language you use, I’m sure it will help you make the call and get buy-in even when you decide you have to override their decision.

Maybe it will even help your managers become less controlling.

Posted in Coaching, Management | Tagged , , , , | Leave a comment

Resolutions

I recently reviewed a list of defect prevention methods published by Capers Jones and Olivier Bonsignour in their book, “Economics of Software Quality.” I was looking for some information to give to my development team so they could choose an option to reduce the number of bugs in their delivered software.

I was surprised to find PSP/TSP was number 6 on the top-10 list with a 44% defect prevention efficiency. The Personal Software Process (PSP) was published by the Software Engineering Institute of Carnegie Mellon University in November of 2000. I’ve reviewed it in the past but I’ve never seen anyone using it.

It’s a straightforward concept, you collect metrics on your own software development. The paper provides a guide to interpreting what the metrics tell you so you can create your own plan to improve your coding. You then use the same metrics to determine the plan’s effectiveness and modify the plan until you meet your goal. The PSP itself is intended to allow a self-motivated individual to become, essentially, his or her own mentor. The Team Software Process (TSP) allows the team to collect the results, but it still assumes you want to be the best you can be.

My team didn’t jump at implementing the PSP either. But this month I sent everyone on the team a challenge inspired by the PSP. I asked each person to come up with one New Year’s Resolution on how they could do their own job better (not limited to the developers). Strangely, even this request didn’t receive immediate and complete compliance. One person went so far as to state he always tried to do his best but didn’t want to select one improvement. And, while I appreciate the sentiment, a general desire to do your best isn’t the same as a focused look at how you do what you do and how you might do that better.

I’ve seen some good resolutions so far. I’ve asked each person to post it at his/her work space (and I’ve posted mine) so we can encourage each other in the resolutions. Even these few will help our team do a better job if the people who made them keep at them.

But what about the others, and what about you?

Are we just too frustrated with resolutions we’ve made in the past to believe we can change our habits? Are we unwilling to take that look at how we work for fear of what we might see? Do we really think we’re as good as it gets? And as the world becomes more Agile, can we avoid taking this kind of look at ourselves?

Most of are very poor at doing work while watching how we work. That’s why sports teams pay coaches. That’s why the concept of Management 2.0 emphasizes coaching and mentoring rather than reviewing and criticizing. And that’s why I’m making this suggestion.

Take a few minutes sometime during the next 7 days after reading this post. Think about why you work the way you do. Think specifically about whether the work habits you’ve created for yourself lead to lower quality work than you might otherwise produce. Ask co-workers for help (especially the best ones). If you find a good idea, make a resolution to change that. Don’t try for more than one as habits are hard to change and you don’t want to discourage yourself. And don’t try for something so broad it’s hard to implement. Do you have trouble staying focused on your priorities? Maybe your resolution can be to review your top 3 priorities at the start of each day to make sure they’re the right ones and you’re making progress. Do you share too little information with your team mates? Maybe your resolution can be to get up and wander twice a day (not on your way to or from a meeting). Pick a resolution and share it so others can help you keep it.

Maybe even post a comment here with it. You might help someone else come up with theirs.

BTW: Mine is to take care of issues now, not when it’s a good time.

Posted in Quality Assurance, Uncategorized | Tagged , , , , , | Leave a comment