How do you fund these Agile projects?

Software professionals are not Lego bricks.

I had the good fortune to finish a training course by Benjamin Day about scrum master skills.  I highly recommend you visit Pluralsight and take his course.  One of the more interesting things about his training was the conversation about how to do annual budgeting with Agile and Scrum.  This week I want to discuss my observations on the subject.

Isaac Socalich wrote a blog post taking about “Legacy thinking” holding back agile adoption at organizations.  He cites the way projects are funded saying accounting practices lead organizations to fund and allocate resources only once around a product, project, or process improvement.  In short, a project has a start, middle, and end.  The people, funding and output of the project are cells in a spreadsheet which manages the project.

This legacy financing model is short sided, counterproductive and the antithesis of the agile movement.  The Agile manifesto stresses “Customer collaboration over contract negotiation,” with legacy financing of projects every activity is reduced to contract negotiation.  The project is conceived with unrealistic expectations.  The deadlines for completion do not reflect the opinions of those doing the work.  Customer considerations are ignored and the funding is at best a guess done by an accountant.  It is no wonder so many software projects fail.  

The most aggravating part of legacy thinking is that treats consultants and people who do the work as machine tools which can be replaced when they are no longer useful.  Teams are created and disbanded based on funding formulas rather than business needs.  This means technical professionals are being treated like mercenaries to build software.  This also creates technical professionals who have no personal investment in the products they are creating.  They are temporary workers billing hours and doing work with no real concern for quality.  

For example, an off-shore team is working on software and because of a lack of funding they are disbanded.  Four months later, the finance department restores funding and a new team is spun up.  The original developers are gone along with the two years of experience they had on the project.  The organization now has to spend the first six months of the project training the off shore team about the business and navigating the legacy code.  The remaining six months of funding is spend attempting to do a year’s worth of labor.  Quality suffers, deadlines are missed and the customer is dissatisfied but the project was correctly funded by the business.

Software teams should be professionals invested in the business and each other rather than disposable Lego bricks.  Projects should be spun up and spun down being given to these project teams.  These teams should remain constant while the projects come and go rather than the other way around.

This is why I like Benjamin Day’s approach so much.  Instead of setting arbitrary deadlines and features to be done by the development team which has no investment in the success of the project, the team is permanent with growing business knowledge and technical skills who take on projects as they are funded.  The business people also concentrate on setting priorities of what gets done.  The project is not thrown over the wall for IT to figure out or fail.  Finally, the business has the right to cancel the project if it is not working.  The team remains to take on the next challenge.  The business either discovers it has working software for the customer and does not need as much funding saving money or has been making a poor investment and can cut its losses.

Over the last fifteen years the Agile Reformation has made great strides in making software development better but it appears that business suites and finance teams are not changing their processes to accommodate this new approach. They do so at the risk to their own business.  Survival is not mandatory and these legacy finance issues will be a cancer in many businesses in the future.  It is up to us in the agile movement to try and help those worth saving.  Otherwise, technologists will be condemned to careers of temporary employment, failure and frustration.

Until next time.

A scrum master should do more than punch a clock

A good scrum master is like a good camp counselor

As we head into summer, it is a good time to reflect on the first half of the year.  I am going through numerous personal and professional changes.  My role is going to be changing at my firm and there are plenty of comings and going.  This week I wanted to discuss some insight I gained at the office.

Many of you know, I am a big fan of Angela Dugan and her blog The TFS Whisperer.  For three days, she came to my firm and conducting training for Visual Studio Team Services and spent quality time with Product Owners at my firm.  What happened next was a revelation.  The following Monday half of the scrum masters in the organization were rolled off.

I think it would be unprofessional and small to discuss the details of why those scrum masters are gone.  Instead, I will say their departure reflects a divide in the agile profession of scrum master.  There are two camps; one camp see being a scrum master as being a glorified project manager, the other camp sees the scrum master as a servant leader, coach, and therapist for development teams.  I belong in the latter camp.

There is plenty of blogs on the web which say that being a scrum master is not being a project manager.  Yet, I see some scrum professionals who see their job as nothing more than scheduling meetings and updating the scrum board too.  This is not being a scrum master.  It is a person accustomed to doing things the old way of attempting to survive in the corporate rat race.  They do not really add value and often create scrum-butt situations.

In my opinion, a scrum master is more than someone who punches a clock and generates reports.  They are more like a camp counselor or youth pastor minus the bad facial hair.  They have to hold other people accountable.  They have to train product owners to a basic level of competence.  They have to make sure that people are shipping working product into production.  Finally, they have to keep people motivated because software development can devolve into a soul-crushing activity.

In short, being a scrum master is hard emotional and intellectual work.  If you are not willing to do that work then you are likely to get rolled off a client.

Until next time.

Process is a lame excuse

Responding to change is like jazz, blues, and rock

One of the central tenants of the agile manifesto is responding to change over following a plan.  For someone with a background in science or engineering it seems commonsense.  Sadly, many people in leadership roles see responding to change as a threat.  This week I want to talk about “process” and why it get in the way of agility.

I have plenty of late nights and early mornings on the phone with off-shore consultants.  These meeting are typical stand-up meetings familiar with co-located teams.  It is also an opportunity to share technical knowledge.  According to the scrum guide, stand up meeting should be fifteen minutes long.  The scrum guide does not take into account a team thirteen time zones away and working with complex legacy system.  So our meeting lasts about thirty minutes and we have follow up calls between individual members.  We have no formal process but the scrum guide is not helpful so we responded to change over following a plan and had a longer meeting.

Many business leader like to say they have processes in place to minimize risk.  It has been my experience that many of those processes are in place to maximize control because those business leaders do not trust their people to do the job correctly.  This makes me sad.  Instead of working with customers and solving problems, many people spend their days wrestling with the bureaucracy and process.  Confronted with this environment people loose initiative and motivation.  Eventually, nothing gets done except the stale process.

This may have worked fifty years ago but product cycles are measured in weeks instead of years today.  People need to be motivated and engaged if the wish to compete in this new business environment.  Process makes it hard for people to be motivated and engaged because it discourages original thinking and ownership of decisions.

That does not deter business leaders from coming up with more process.  To them, a business is like a symphony orchestra with every not scripted and every performer knowing his or her place.  If someone deviates from the music sheet or the conductors instructions then they are expelled.  I strongly disagree with this metaphor, I see a business like a jazz or blues combo.  The players have strong technical skills but com improvise based on the situation and can adapt to changing situations with the audience.  To a command and control business leader, this is unacceptable and a recipe for chaos.  To the agilest, it is responding to change over following a plan.

One of my favorite stories about Jazz history is about Benny Goodman.  A critic said his music was immature and untrained.  Goodman responded by recording Mozart’s Clarinet Quintet in A major to critical and popular acclaim.  In a more modern context Wynton Marsalis plays trumpet in both jazz in classical situations.  Finally, Trombone Shorty easily transitions between Jazz and Rock music.  In short, it is common for jazz musicians to cross over into other styles of music while it is uncommon for classical performers to do so.  I blame the “process” of training and conditioning of classical musicians who struggle in ambiguous creative environments.

This is the big challenge of business.  Do we want our employees to be like classical musicians of like jazz musicians?  In my opinion, I am going to trust my business to the jazz nerds.  The will be able to respond to change when necessary.  This is why I rebel against process.  I see process as a necessary evil.  I also see it fungible and able to change.  This drives my superiors crazy because sometimes the process is the only thing which keeps them in control.  Squeaky wheels often call attention to a bad axle and managers hate that.

So I say to you, treat process with contempt and skepticism because it is an excuse for behavior at a company rather than a reason.  This makes it impossible to respond to change.  W.E. Deming said, “Survival is not mandatory,” if you follow process chances are you are more likely to become extinct.

Until next time.

When to hang it up

Sometimes you have to pack your bags.

Last week I spoke about “struggle” and what I felt it meant.  It inspired a strong reaction from a few people.  Watching this reaction, it dawned on me, I was witnessing a conversation I had three years ago.  Each of us have moments in our careers where we consider leaving and going someplace else. Some of us have that choice forced upon us while others have a “moment of clarity” and then give their notice to their boss.  This week I want to talk about when it is time to leave.

I have been a software consultant and full time software developer for many years.  It was filled with frustration and failure.  Additionally, when I was a consultant I was often treated like high paid “help” who was supposed to keep his head down, mouth shut, and ignore the dysfunction which surrounded me.  I even completed a project early for a client and instead of being rewarded with an extension I was thanked and promptly rolled off.  I have been fired a week before Christmas and had to explain it my former spouse.  I have looked over my shoulder worried I was not good enough and smart enough to work with the other developers in my company.  I needed to make change.

With my own money, I took my Certified Scrum Master training.  I was feeling despair and working as a heads down developer was taking a toll on me.  This was a chance to practice what I preached about Agile.  After becoming an architect at a different firm, they learned about my Scrum Master training and made me the servant leader of development team.  Looking back on that experience, I realize that I was raw, cocky and untested.  One developer openly rebelled against me right away and I would spend weeks and months attempting to effect change.

That was three years ago.  Now, I am training product owners for division of my company, serving as a scrum master, and being “spun off” as my firm splits into three companies.  In those three years, being in the trenches as a scrum master has made me a much better servant leader.  I am even participating in the company mentoring program.  I voiced that I was restless and frustrated with the pace of change I am trying to effect and it looks like someone listened. For me, it is a sign that I need to stay because big changes are coming and my peers and superiors see that I should be part of that change.

I will only speak for myself but if you cannot get training through your work and if you are asked to do one thing but are rewarded for doing something else then it is time to leave.  Before I started working as a scrum master, I was a senior developer for a food company.  I was talking about a software project with a superior and he said I should start over because it didn’t look like something he could use on his iPad.  It was the final straw and with-in a month I was gone.  Since then, that company has paid hundreds of thousands of dollars in agile consulting and they laid-off over 100 people, mostly older workers, in order to be more nimble.  They could have saved a lot of money and preserved those jobs if they just figured out how to keep me and allow me to spread agile through the firm.  I am glad I am no longer there.

Each member of the agile community is responsible for his or her own career.  We have to make choices every day about what we do and who we serve.  We also need to remember that we need to serve ourselves.  If we are unhappy or frustrated with what we are doing then we need to change.  If that means leaving one company to go to another then so be it.  For me, I am staying where I am.  I am entering an exciting time of change and I look forward to the challenges.  When I can’t say that any more then I have to quit.

Until next time.