April 19, 2014

All Posts In Category: Project Management

Agile Coaching Blog

But It’s Just a Simple Matter of Coding – How Hard Could It Be?

Many times, I hear business people (such as Product Owners) bemoan how expensive software development is.  And the brutal truth is that for anything non-trivial, software costs a ton of money to develop.  I happened upon some numbers for a fairly simple but elegant iOS app called “Twitterrific”.  Twitterrific is a client to the Twitter network, uses a well defined interface created by Twitter, and does not require any backend development.  It runs on the iOS, which is a well defined, well documented, well supported, and stable environment for both development and use.  According to an article published on the PadGadget site, Twitterrific was developed by a single person (Craig Hockenberry) in about 1100 hours.  The article goes on to do the math at $150/hour, adds in design, testing, and so on, and comes up with a number of around $250K.  That’s just for labor.  No costs for a workplace, infrastructure, developer tools, and so on.  Once you start adding in enterprise costs for offices, management labor, etc., and start building multiple tier complex applications, It’s easy to see why business people would look at the finished work (knowing how they interact with computers, which has become easier and easier over the years) and wonder “How hard could it be?”

That burning issue perplexes many organizations.  It isn’t usually an issue with companies with disruptive products – when margins are huge, things become profitable quickly and easily.  It isn’t usually an issue with a young, well funded company – if there is a long enough runway covered in money, and you aren’t accountable for showing profits until sometime far down the road, costs are not the issue.  However, it is a huge issue in many enterprise IT settings, where capitalized expenditures are rigorously scrutinized to see what work can be done under the funding constraints that exist. So, why is software such an expensive thing to create?

Here are four reasons that I find compelling.

  1. For anything other than trivial software, the potential for failure due to complexity and development risks is huge.  Back when mainframes ruled the earth in the 60s and 70s, the average program was thousands of lines of code. Today, it is very common to see applications that are tens of millions of lines of code. And, since any line of code can potentially affect any other line of code through side effects, a program that is 10 million lines of code is one million times more complicated than a program that is 10 thousand lines of code (a so called “n squared” problem).  The care needed to create code that works at all, and the potential to have bugs emerge is astronomically high.  While we have better tools now than we had forty or fifty years ago, they aren’t a million times better.  Trust me!  I developed software on machines back then as well as now.
  2. Programming is more like an art than it is engineering.  Engineering and building large and useful things on schedule has become commonplace nowadays, and people count on it.  For example, Tommy Lennhamn (from IBM), states that “Examples of successful engineering projects, at least with respect to schedule, are all the construction projects for Olympic Games — as far as I know, all Olympic Games have started on time, on fundamentally new premises.”  The secret is that with engineering problems for things like constructing buildings, components to build from are well known, assemble together well, and don’t create too many unknown side effects when bolted together.  In that type of situation the hard part about the project is agreeing on what to build.  With software, many times the business doesn’t know what to build until they build something to see if it solves the problem.  But that operates in a doubly damning world where developers don’t have the components that assemble together without knowing for sure if their construction in one place has affected something else (and someone else) in the code base.  Not withstanding the efforts of TDD, we can never prove correctness in software to the same extent that we can with mechanical construction.
  3. Not all developers are created equal.  The barrier to enter the field is relatively low.  This attracts a lot of people to compete for relatively high paying jobs.  But, as people like Steve McConnell point out (in IEEE Software, Vol. 15, No. 2), “…differences of more than 20 to 1 in the time required by different developers to debug the same problem” exist.  Does it make more sense to hire one awesome person for $200K or 10 mediocre people for $90K each?  Remember, once you hire 10 people, communication issues will slow you down (Fred Brooks “Mythical Man Month” stuff, but I digress).  While there may be a glut of cheaper labor today relative to the salary requirements of the awesome developers (due to such factors as geographic outsourcing), the reality is most enterprise IT settings would never hire the really awesome developer at a relatively high pay grade, due to political issues. And, even if they could, they would be hard pressed to find talent willing to work in the stodgy environments that many enterprise IT settings have become.
  4. There is still a wall of disengagement between business and development that needs to be broken down.  The Agile movement of the last 13 years has done a lot to publicize the need to have “Product Owners” engage on at least a daily basis (with continuous engagement being the best), but it is still very common to see business people physically and geographically separated from development.  Worse yet is when enterprise business people complain about how much “more important” work they have to do, and how they yearn to return to the days of yesteryear, when they could ask the Project Manager for a status update, and then complain when things were behind schedule.  Lean thinking tells us that faster feedback loop cycles will create less waste, and therefore more and better product.  Given the realities of 1-3 above, and the cost associated with those items, I implore such business people to stay with the development teams and help them help you reach the enterprise’s goals.

It’s a shame that software is so exquisitely expensive to make, as the opportunities to enrich our lives by using relatively cheap hardware is everywhere.  Everything from smart thermostats (such as the “Nest”) to smart light (such as the Philips Hue) to truly personal computers (such as Samsung Galaxy Gear and Google Glass) surrounds us.  And it all takes programming computers in one way, shape, or form.  Unhappily, programming computers is anything but easy.  But if you consider that humans have been building houses, roads, and bridges for thousands of years, and are still faced with colossal failures from time to time, it sort of puts things into perspective.  Programming will continue to evolve into something more of an engineering practice someday, and programming may eventually become something relatively simple.  Of course, we’ll have to find something else to complain about if that ever occurs!

Kinky for Governor Poster

Kinky Friedman ran for governor of Texas in 2006 on the slogan is “How Hard Could It Be?” While this was a great line, no one, including Kinky himself, ever believed it. Even Kinky admitted that “I’ll hire good people!”

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

Share:

The Essence of Agility: Becoming Safer by Controlling Less

The other day, I presented at Agile India 2014 on the topic of “Pivoting Your Organization to Become Agile Testers”. Near the end, when I was tying up all the points in the talk, I was speaking about wastes that come from “big batch thinking” and gave an analogy off the cuff (and way off my talking points!) to illustrate why the most useful testing should be automated at a product functionality level.  The analogy I conjured up is powerful, and is an application of lean thinking that has value in so many enterprise-type organizations.  The basic message is that by planning less (not attempting to not try to preplan so such about how things will work, but instead concentrate on showing that things actually are working) and lightening up on process controls, we can gain a lot in the sense of getting actual stuff done, and not just measuring the busy work that accompanies getting that stuff done.

The analogy I used has to do with cars and the flow of traffic.  It starts with the 20th century concept of separating drivers from pedestrians, which was developed to keep pedestrians safe from fast moving cars and to allow cars to be driven without constantly fearing that they might run into pedestrians.  As wider and faster roads developed, the need to use road signage and traffic signals to control the flow of movement became both an expectation and a necessity.  But the traffic signs and signals had an unintended consequence.  Drivers felt that if they simply obeyed what the signs told them that they were allowed to do, they could be safe in just driving and not have to worry about the current conditions or how they needed to react to them.  Some people slowly began to question these assumptions.  For example, Hans Monderman, the Dutch road traffic engineer behind the Drachten Experiment (more about that in a minute), has said, “A wide road with a lot of signs is telling a story.  It’s saying, go ahead, don’t worry, go as fast as you want, there’s no need to pay attention to your surroundings. And that’s a very dangerous message.”

An interesting way of “seeing” the issue of inattention when concentrating on a task at hand is to experience “The Monkey Business Illusion”.  Take a minute to try the YouTube video and play along!

)

Are you back?  How did you do?  Think of how this applies to driving, and maybe even some close calls you had when driving.  When our attention is on task to do something specific asked of us, such as “Count how many times the players wearing white pass the ball”, or “Speed Limit 50 MPH”, we can easily lose the bigger perspective of very important things.

Anyhow, back to “The Drachten Experiment”.  Drachten, a Dutch town in the Netherlands, is an old medieval city that has been growing steadily in the past 60 years.  The town had a problem that it wanted to solve.  It wanted to lessen downtown traffic congestion and reduce traffic accident rates at the same time.  For 100 years, the accepted way to accomplish this has been to separate people and vehicles, introduce road signs and traffic signals, and have strict rules on who has the right of way and when.  But the town had enough of that school of thought, and felt it could go better by doing something which seemed weird at first glance.

What Monderman did for Drachten was to remove all of the traffic lights and road signs from the town’s center.  This had the effect of reducing accidents from about 8 per year before the experiment to about 1 per year after the experiment.  Throughput, even in the face of additional traffic numbers, has increased with average measured delays reduced from about 50 seconds to between 10 and 30 seconds.  An explanation of the reduction in accident rates is that many drivers habitually race through traffic lights right before they turn red.  They get lulled into a false sense of security by the confidence that they have right of way – making them less aware of potential hazards, such as people that are anticipating the changing traffic signal and ready to assert their right of way.  Perhaps you can recall an experience like that.  It usually evokes pangs of anxiety as we think about what could have happened.

Drachten before Hans Monderman.

 

Drachten after Hans Monderman.

The trouble is that we have the same sorts of issues when we do traditional project management.  We preplan the dependencies, map out what the expectations for what final integration will be, and then start reporting on how close each sub-project is towards the ultimate goal.  We install our own forms of traffic signals, called “gates” in traditional project management, and have fairly high ceremony events, using terms like “go / no go” decision points.  In our zeal to track and manage progress towards the ultimate goal, we can be blinded to the actual problems facing the project.  The false security that we get from showing progress against the plan, by using the process we employ, can blind us to the fact that a gorilla has come on the stage, that the curtain has changed color, or that our car now poses a treat to a pedestrian entering the cross walk.  Successful projects don’t get that way by just being right on the process.  They have to pay attention to the right things that change, and make sure that the relevant issues are surfaced as quickly as possible to avoid last minute close class (or worse!)  Letting go of some process gives much better results than rigid control of flow.  That’s what agile planning is all about.

Lao-tsu, in the Tao Te Ching, said it best:

Stop trying to control. Let go of fixed plans and concepts, and the world will govern itself.  The more prohibitions you have, the less virtuous people will be.
….
If you don’t trust the people, you make them untrustworthy.

We hire good people to work for us.  We owe it to them to trust them to do the jobs they were hired to do.  As leaders, it’s our job to ensure that the organization is configured to allow that to occur and that there are as few road signs and traffic signals as we can get away with.  We don’t need false senses of security.  We need results.  Reduce the control points down to where people act as people, see the whole picture, and can act appropriately.  That’s the essence of agility, and where we need to be.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

Share:

Will Agile Process Work For My Project? Defined vs. Empirical

As an Agile Coach I often get a question about when Agile frameworks should or should not be used. One of these is whether or not an Agile framework is suitable for a particular project or product. This question is not easy to answer, especially since the one asking the question has more knowledge of the proposed work than I do!

One thinking tool to help make such a decision is to contrast “defined process control” with “empirical process control.” This video explains what I mean.

Is your project or product definable before you start working or do you need empirical data to help build the solution? Looking for more clarification on this topic or anything else agile? Just ask, we will do our best to get you started in the right direction!

It’s kinda nice having a coach in your corner, right?

Share:

Agile Planning: Why it’s hard to say when

A couple of weeks ago I was leading a story mapping workshop. As I was explaining the process several questions came up around knowing when things would get done. Since we were just getting started, that moment was not the time for a answering questions of when.

When to Answer When

The work of turning ideas into product features involves many questions, only one of which is when. The trick is when will a feature or set of features be complete is not directly answerable. All the other questions and their answers feed the schedule answer and cannot be ignored. We can answer when only as we answer the other needful questions.

Why?

The obvious answer is that you want to get paid, to make a profit. It is possible that the motivations to do the work are more and different than profit. Motivations have bearing on schedule.

Who?

Who your users are and the market you are targeting certainly effects when the work needs to be done. Different markets and different users have their own needs for timing and expectations.

What?

What the product does and what value it brings to your customers are among the more important points to understand well.

How?

The development teams answer this question by understanding technology, tools and experience. Estimations are part of the how answer because size of effort is directly tied to the people doing the work.

We can only answer when, when [grin] we have answers from the questions above. When sits in the middle of all the other questions and is directly affected by choices we make in their realms.

See how it is hard to say when?

Agile Planning and When

Part of the power in Agile frameworks is the separation of product questions so that they each get the attention needed. Agile frameworks only work well when feedback from all the other questions helps determine when. Agile frameworks give us two ways of answering when and only one direct manipulator of when.

The first way is fixed date, variable scope: When the date is fixed, it’s still just a day on the calendar. In this case the number of features that will be completed by that date, the scope, is necessarily variable. (Even if we don’t want it to be.) We ship everything that is complete on that date. Since Agile frameworks require that the product be maintained in a shippable state, picking a ship date is not hard.

The second way is variable date, fixed scope: If the minimum marketable feature set is large, meaning we have defined a fixed scope of features, the ship date is variable. When to ship is answered given by the date all of the minimum features are complete.

(It is important to note that Agile frameworks do not provide for a way to have both fixed schedule and fixed scope. Neither does any other way of working. It is just that we pretend that we can fix scope and schedule. We in the software industry have been largely failing to do fixed schedule and fixed scope software development for decades. Agile frameworks are empirical processes, where we adjust our work based on the information we gather while doing the work. Fixed answers to when and what are not supported in empirical work. But this is a larger and different discussion.)

The one direct manipulator for answering the question of when is priority. In other words, we can ensure a feature is done before a given date by deciding to work on that feature first. This is why it is so important to take the time to order your backlog with the most important, valuable, risky, etc. features at the top, to be worked on and completed soonest.

Division of Answers

Agile frameworks provide for a division of responsibility in part so that we can get answers to these questions. This way each question is supposed to get deserved focus. For example, in Scrum the Product Owner is the role that focuses most on the question of what should be created. The development team owns the question how. The teams help stakeholders and others answer who and why. These divisions are not walls but areas of focus, as every role informs the other roles and questions. And every question feeds to answer when.

When is in the middle.

When is in the middle.

Share:

Sense-and-Respond: A Broad Organizational Capability

In order to avoid the pitfalls of myopic agility, it can be helpful, if not downright prudent, for you as a leader to broaden the lens through which you think about the very notion of agility. You want to move your thinking beyond just teams.

I invite you to think of agility in the following most general, most widely applicable terms:

Agility is the capacity to effectively sense and respond to—and ultimately shape—events, situations, and conditions in order to enhance a system’s (individual’s, team’s, organization’s) ability to thrive in ever-changing environments and conditions.

Let’s first examine the key terms sense and respond and then turn to the implications for managers and leaders who wish to bring about a broader, organizational agility.

Sensing

Agility & Sensing
Sensing means having acute and accurate awareness of what’s going on. Often, however, filters exist which either obscure or distort reality. Common examples include: [Read more...]

Share:

Personal Kanban: Week One, Dysfunction Goes to Eleven

Editor’s note: One of our agile coaches and Scrum trainers, Dave Prior, has been keeping a log of his experience using Kanban to manage his own work. You can follow his adventures every other week on our blog.

When this experiment started one of my goals for the first time box/iteration was just to see if I could actually give up my Things task list and follow the practice with a board. I had tried a number of other productivity frameworks and found that only pieces of them stuck. (Someday someone will write on a book on how to finish David Allen’s “Getting Things Done” book and I’ll actually get all the way through it.) And while I know that limiting work in progress is a cornerstone of this type of approach, and I did set WIP limits, I decided to be a little loose with the limits since I was just guessing at what they should be.

Because my larger plan is to test out different approaches to Personal Kanban, I wanted to start as simply as I could manage. I created a task board and began to fill it with post-its. The first lesson I learned was that I had far too much in my to do list to fit on my Kanban board. I decided to limit it to the things that seemed to be the most important at the time.

The Architect of My Own Demise

The most basic way to set up my board would have been to create three columns: On Deck, Doing and Done. I know this. However, when I sat down to work on it, I began struggling with how I would be able to visually understand the different types of things I had to do. [Read more...]

Share:

Personal Kanban: One Agile Coach’s Journey

Editor’s note: One of our agile coaches and Scrum trainers, Dave Prior, has been keeping a log of his experience using Kanban to manage his own work. You can follow his adventures every other week on our blog.

I am fairly well versed in how to manage projects. For the past 18 years I have been developing my skills at helping people manage the work they have to do into a state of ninja-like perfection-ish. As I have progressed in my career I have had the good fortune to work on projects of varying size, duration, and cost. Some have been successful, but more have not – and that is okay because those are the ones where I’ve learned the most. To demonstrate my proficiency in my chosen profession I have obtained multiple certifications in project management and agile development. I’ve even spent years teaching others how to get those same certifications. Along the way I also got an MBA to demonstrate… whatever it is an MBA is actually supposed to demonstrate beyond that I am willing to be in debt until I go to my grave. And I’ve given up thousands of hours of personal time leading volunteer organizations that focus in managing work and teaching people how to get better at it. My experiences have taught me many things… most of them the hard way. And with this, I have found only one single truth that spans all of it:

Being skilled at helping others manage their work is no guarantee you will demonstrate any level of skill at managing your own. In fact, I think it is fair to say I pretty much suck at managing my own work. I’m not saying I am not good at getting things done. I get stuff done all day long, and usually, it is the most important stuff. But I’m not good at managing it.

Why Managing Work Is So Hard Nowadays

When I started working in project management, managing stuff was not a problem. [Read more...]

Share: