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.

Advertisements
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

The art of the small

First, my apologies for skipping more than an entire year. I knew it had been a while, but I hadn’t realized my last post was in December of 2014. My resolution for 2016 is to be more regular.

Most developers have a habit of delivering a lot of code at one time. In many ways the world of Java encourages this and helps developers create habits that are hard to overcome. Even a simple application requires several steps and files to render something useful, especially if you want to follow best practices with interfaces and resources. The result is that making anything work takes a fair bit of overhead. Nobody likes doing all that work and having a very little to show for it.

I’ve experienced this myself. When I add a page to an application my preference is simply to make sure I can navigate to and from the page first. Then I can start putting in the functionality. I can add functionality in small steps with full regression testing to ensure the additions don’t break working code. But I am not just tempted to cut corners, I often give in (although I’m usually reminded why I prefer to go small almost immediately).

There’s more involved, though. My current project is not fully Agile, and our CIO had asked that we stop making updates during a critical season. This meant that our end users overloaded what was intended to be the “last” release before that critical season began. (Naturally, this overloaded release was the worst we’ve ever had.) When end users are concerned about when the following release will happen they naturally want lots of functionality included in the upcoming release.

For these reasons and more there are pressures to release code in big-bang releases. But the biggest reason of all is it isn’t always easy to see how you can make a release smaller. This is an art and one that you need to cultivate in your team members.

As an obvious example, our system is a replacement for a completely manual process. We aren’t replacing any existing tech. When the end users were giving us their requirements they had business rules that they wanted our application to enforce. These were complicated rules and sometimes they conflicted. They also significantly increased our time to complete the initial release.

My tongue-in-cheek suggestion for release 1 was to akin to scanning the paperwork into a computer for viewing in PDF form. But in reality I would have recommended a system that replicated the manual process as much as possible. This meant not including the business rules at all. Since the future end-users already knew all the business rules there’s no reason to enforce them from in software, at least not in release 1. This is just one way to reduce the size of the initial release to a manageable size.

But there is much more you can do. Start working with the following exercise: Instead of asking what is necessary to make the system complete, ask yourself what is the minimum value we can add, and what is necessary to add only that. If you make each increment the answer to this question you will have made huge strides in the art of the small.

Posted in Coaching, Development, Quality Assurance, Success | Tagged , , , , , | Leave a comment

Not If But When

I hear this over and over and over. “We didn’t have time to write automated unit tests and now regression bugs are killing us.”

People always struggle with the cost of quality, but the cost of quality can’t be avoided. It can only bey delayed, and as it is delayed it compounds. To keep the cost low, you need to address it immediately.

If you’re going to build and design as you go (more on that in another post) then you have to be free to change your design as you go. And if you don’t have automated unit tests changing your design is a crap-shoot early in the project and somewhere between trouble and disaster later in the project. In addition, as you go you know you will need to refactor your code and you have to have good automated unit testing to know the refactor was successful.

Can’t you just test manually? You can if it’s a simple and small application. But with each build the regression demand increases. With any but the smallest application your time required to test a build will eventually overwhelm the time available to run the tests. Automated unit tests are the only way to keep up.

If your current project doesn’t have good automated test coverage then you are caught in a very difficult place. I recommend paying the penalty as soon as possible since it only becomes more expensive with time.

More importantly, I want to convince you to never start another project without including comprehensive automated unit testing. Use test-driven development if at all possible. If you can’t do that then make a full automated set of tests a part of your definition of done.

But what if you aren’t very good at coming up with test assertions? If that’s the case, find a mentor or do some studying and improve. But until then write the best test cases you can. At least you’ll have those to help you minimize bugs. If you add a test for every bug found in later testing your suite will quickly become the suite you need it to be.

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