Monday, August 22, 2016

I Can't Believe I was Being this Dumb

I can learn a few things from this guy.
A scrum master is a leader without any authority.  They are someone you follow because they help you become a better developer and help you finish projects in a timely manner.  It is not for everyone.  I spend much of my time in self-reflection and attempting to improve my skills.  I also have to control my autocratic and curmudgeonly nature when I am dealing with individuals who are not pulling their weight.  On twitter, I had an interesting interaction with someone I respect in the user experience field Gail Swanson and I think there are a few lessons to be shared.

Like many of us, she uses twitter as a place to vent frustrations, test out ideas and share knowledge.  I respect her and follow her because she has plenty of things to say about being a good user experience person.  Then she shared this on twitter.

I responded with the following
Finally, Angela Dugan chimed in and she might as well have dropped a mike.

It took some time for this to sink in but it dawned on me that words and behaviors matter.  What I consider being respectful to my developers comes off as condescending and superior.  How I spoke to them effected their performance and it need to change right away.  I was being dumb.  So now, I use the terms “everybody”, “team” or “folks” to refer to the people I am working with.  I was doing something dumb and it took people I respected to point it out to me.

A contemporary scrum master has to interact with numerous people.  They work with off shore teams and on shore teams.  They are mixed by gender and religious affiliation.  I have Sikh, Muslims and Hindus working for me off shore.  On shore, I deal with evangelical Protestants, Neo-Pagans and Atheists.  What unites all of us is that we know how to code and that we are working on the same project.  I as the scrum master need to respect these cultural differences and keep everyone focused on the end goal.  My personal feelings or prejudices need to called out and controlled if I am going to guide these individuals to their goal.

It also means that the macho cruft that you see in software development needs to go away.  I am fortunate enough to work at an organization where women are incorporated into all of the development teams.  I think that has improved the development teams.  The testers, technical leads, developers, and QA people who are female are regular members of the teams and because of their skills have earned the respect of their male colleagues.  For our organization, diversity produces better results.

So there you have it; a scrum master needs to change and adapt.  The increase of off-shore development and the number of woman in the profession, has made me confront some of my own prejudices and make changes. I hope others can learn from my example.  I am just trying to be a better scrum master and guy.

Until next time.

Monday, August 15, 2016

If it isn't broke you better fix it.

This didn't have to happen.
I have been off line for a week as I attended the Gen-Con game fair in Indianapolis and tried to get back into the swing of things at work.  While I was away, I had a chance to recharge my batteries and have a good time playing board games with friends.  I also got to have a little fun with the people at Big Potato Games which is seems like a fun group of people who are making a big splash in the industry.  When I came back two things happened which got my attention which illustrated the paradox of contemporary business and modern technology.

The first was the problem with Delta Airlines and its reservation system which grounded the company for two days.  The second was a small article in the technology press about Windows 10 updates.  Both articles illustrate to me that the business maxim, “…if it isn’t broke don’t fix it,” is seriously wrong.  If you are a company in the 21st century if you want to remain in business it is your responsibility to upgrade your technology infrastructure and applications.

First, Delta airlines relies on its reservation system to be managed on AS/400 systems and mainframes using the IBM Transaction Processing Facility software.  The software was last upgraded by IBM ten years ago and the only people who can fix something if anything goes wrong are IBM consultants.  If something goes wrong a CIO and their company is forced to call IBM to make changes and corrections.  In the same ten year span, Microsoft has had four operating systems; Windows 7, Vista, Windows 8 and Windows 10.  Presently, there is an entire ecosystem of developers outside of Microsoft who can alter, improve or fix these systems.  So if an airline wants more availability to labor and more up to date systems they should go with a Microsoft solution.

This did not happen for a few reasons.  First, airlines for all their talk of customer service and being high tech are notoriously stingy with money to upgrade and improve their technology infrastructure.  So what they did is graft other technology systems on to their old IBM infrastructure.  If the AS/400 went down, it would create a cascading effect which would shut down the airline.  According to the news, that is exactly what happened as numerous technology professionals scrambled to get the systems back up and running.  It also lead to the CEO of the company publicly admitting they are doing the best they could to fix the problem without knowing exactly what went wrong.    Next, the people who make the decisions about the funding felt this risk was so unlikely that they decided that the system was not broken and so they did not need to make improvements.

This kind of thinking is foolish.  Software is like any other machine but it manufactured out of ones and zeros instead of steel.  Machinery needs to be maintained or it will break down.  Fail to change the oil in your car and see what happens after 100,000 miles.  That is the exact situation which happened at Delta. The people driving the organization put off or ignored routine maintenance to its systems because it would cost money to do so.  As long as everything was working, there was no need to do maintenance and upgrades.  As you can see, this cost the company millions of dollars when the system failed and hurt its reputation for quality service.

The other new item I saw this week was a brief blurb about how Windows 10 updates are not an iron clad guarantee that a system will not be compromised by hackers because people generally do not upgrade the other software on their machines.  As a technology professional we have seen people with Windows 10 machines with copies of Office 2007 on them.  This mixing and matching of software in the real world is common because people don’t have the money to upgrade everything.  This creates openings for hackers and people willing to do bad things.

This is short sided like a person not changing the oil in their car.  When you upgrade an operating system you should be able to update the software which is on that operating system.  This is why I am a big fan of Google Documents and Microsoft’s Office 365 software because these cloud based systems update automatically and do not rely on the user purchasing and installing upgrades.  The burden is no longer on the consumer but on the company providing the software which is what it should be.

So in one week the world witnessed an object lesson in why the phrases, “…if it isn’t broke don’t fix it,” is wrong.  Old and outdated software which was not maintained properly failed spectacularly.  The only people who could fix the software was a third party vendor which was not responsive.  The pennies saved on upgrades and improvements became millions of dollars in technical debt which shut down the company.  Finally, the reputation of the company was hurt by this kind of thinking.

It is also clear that just upgrading operating systems is not enough the applications which run on those operating systems need to be improved.  I understand that in the world of technology bragging about your new data center or software upgrades to your core business is not as glamorous as web application or phone app but it is just as important because when those systems fail they fail in an embarrassing and spectacular fashion.  So it is up to everyone from the largest company to the personal consumer to pay attention to how they maintain their software.  If not, expect to be grounded.

Until next time.

Monday, August 1, 2016

When your office resembles high school

We grow up but never out of high school
When I was a high school student, I had an irrational fantasy about being an adult.  I truly believed when I left school, I would enter an adult world and be surrounded by grown-ups acting in grown up ways.  In the thirty years since high school, I have been bitterly disappointed. This week a few thoughts about how your office resembles high school.

Any American who attended a public high school knows that the students live in a social and cultural limbo. Over achieving strivers are wedged together with cheerleaders.  Hard rock students in black concert shirts walk the hallways with people into hip-hop wearing track suites.  The public high school is one of the few places where people from different economic circumstances, races, and levels of educational acumen are forces to interact with each other.  Naturally, they self-separated and create tribes.

As a dorky kid, I was both outcast and court jester for the insular and sad world.  Eventually, I found a niche in forensics to develop my public speaking and in JROTC to improve my self-discipline. The formative time shaped me into what I am today.

To my surprise, the mean girls who tormented me in school would resurface as marketing, human resources, and project management professionals.  The homecoming kings and athletes would transform into sales professionals and executives.  The dorky people who said not to drugs, studies hard, and developed insane technical skills.  We still answer to these monster in corporate environments.  No wonder so many of us become entrepreneurs.

The first thing I have learned is that mean girls grow up to be mean woman.  I have also learned that mean people are not worth your emotional energy.  They are going to remain mean so the best strategy is to ignore them or treat them with the contempt they deserve.  Telling someone they are being a jerk is the first step in getting them to change.  It is also good to point out to their bosses that the mean person’s attitude is why projects are not getting done on time or on budget.  You will be pleasantly surprised what happens next.  A good leader will fix that situation immediately.

As for the athletes and popular people who become executives, I have found listening to sports radio and watching ESPN sports center gives me enough knowledge to talk sports without sounding totally clueless.  It also allows you to use sports metaphors to describe technical situations.  For instance, I was building a web site and running into problems with the corporate active directory.  I told a boss that the situation was like a basketball team with a player who won’t pass the ball.  A few phone calls later my issue was fixed.

I am not suggesting that you become a tattle tale but I have discovered that when interpersonal issues prevent a project getting completed leaders behave like a high school principle and step in.  It is not pretty but in a world where dollars and cents count.  The person who gets work done is always going to receive preferential treatment over the person preventing that from happening.

So none of us really escape high school but hopefully as adults we can deal with the people who act like they are still in it.

Until next time.

Monday, July 25, 2016

Lessons learned being a scrum master

Failure is just part of being a good coach.
Being a scrum master is more than taking a test and receiving a certification.  There are plenty of hours of hard work and endless meetings.  As a rookie scrum master, I thought I understood the role.  Today, I know better.  This week some lessons learned.

When you discuss the term servant-leadership, many scrum masters see the developers they work with as servants.  This is backward.  A scrum master is a servant to the development team.  They provide help and guidance where they can they take care of the other team members before they take care of themselves. Most people see rank as having privileges; I disagree.  Rank is about responsibility for others, fulfilling those responsibilities and receiving only the privileges which benefit the entire team.

I am an extroverted person and according to the Myers-Briggs personality test I fit the model of charismatic leadership.  This is great for politics or giving presentations to a room full of fanboys but it is a handicap for a scrum master.  The reason is this leadership style means you talk more than you listen.  This is a recipe for failure for a scrum master.  To make change and coach others you need to listen and observer with the attention to detail of an anthropologist out in the field.  One of my early mentors, Andy LaChapelle said it best, “You have two ears and one mouth use them in that frequency.”

Finally, to be a scrum master is to let others do the work.  This has been the hardest lesson to internalize.  I have been a Type “A” person with plenty of nervous energy. When a task was incomplete, I would step in and finish it.  That is wrong and like an NFL coach going into a game to kick a field goal.  The scrum master is the coach and it is up to them to let the team members succeed and fail on their own terms.  It is maddening but so is coaching a team all week getting them in a position to win and have the kicker miss a field goal.

So experience has taught me that to be a successful scrum master you need to be a servant leader putting yourself above others.  A successful scrum master listens more than he speaks.  Finally, a successful scrum master lets the team do the work and self-organize.  I hope you take these lessons to heart so you don’t have to learn them the hard way like I did.

Until next time.

Monday, July 18, 2016

What Donald Rumsfield can tell us about being a Scrum Master

Donald Rumsfield back in the day.
Donald Rumsfield is going to be a controversial figure in history.  The Princeton graduate will be the center of plenty of scholarship about the Iraq war and the events surrounding the September 11th attacks.  Looking over his conduct of the Department of Defense and business career, I am not a big fan of his leadership style.  What I do acknowledge is his famous quotation about ambiguity and uncertainty.

“There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know.”

This week on the blog some things a scrum master can learn about ambiguity from the former Secretary of Defense.


Known-Knowns

Every scrum master confronts these each day of their career.  The coffee pot is broken.  Active Directory permissions are not correct for a developer and the compliance committee will not allow a production push for two weeks.  These are the known-knowns.  They are the daily challenges and impediments which crop up and are expected.  These issues are easily solvable, have been solved in the past, or can be ignored with little risk.  As a scrum master it is your job to sweep these kinds of issues out of the way to make your team successful.


Known-Unknowns

This is what traditional project managers call risk.  These are situation which can plan for but might not happen.  The most famous example is Eisenhower’s communique he was to send if the D-Day invasion failed.  As a scrum master, things can go horribly wrong and allowances for these things are necessary.

This situation also happens when developers are asked to do something they have not done before.  In my case, it is using modal forms with Bootstrap 3.  This known unknown is taking longer than I expected to implement.  If I have more serious time pressures, I would use a different approach on the website I am refactoring.  I am learning this new skill and taking the time to master it because it will transform into a known-known if I do the work.


Unknown-Unknown

These are the surprises, calamities and disasters that befall a development team.  The production server has not been upgraded to the latest version of the .Net framework.  The network administrator won the lottery and had tenured his resignation immediately.  Finally, the third party API the application relies on changes without notice.  An unknown-unknown quickly becomes a known-known because of the severity of its impact.

These land mines are silent and deadly traps which make the life miserable for a scrum master and technical professionals the serve.  It has been my experience that many of these unknown-unknowns are the product of technical debt.  So to reduce the amount of ugly surprises, reduce the amount of technical debt.


Unknown-Knowns

Salvoj Zizek, a philosopher and cultural critic mentioned there is a fourth category which Rumsfield neglects.  The is the world of the Unknown-Known.  This is a piece of knowledge you have which you chose to ignore.  An example of this could be a tech-lead who refuses to write unit tests because his “code does not have bugs.”  In my experience, the situation crops up because politics, prejudice, or human nature prevents us from acknowledging the evidence we are confronted.  You see this situation in co-dependent relationships and dysfunctional teams.  It is the duty of a scrum master to call this out and make sure that developers are aware of everything they need to be successful.

A scrum master needs to understand and confront the known-knowns, the known-unknowns, the unknown-unknowns and the unknown-knowns facing his team.  Otherwise, the project might go as smoothly as the Invasion of Iraq.

Until next time.

Monday, July 11, 2016

Rethinking how I look at story points.

Story points are not like coffee cups
I have been an agilest since 2009 and that means that my knowledge of scrum and agile have grown over time.  Occasionally, I have to reconsider some ideas I took for granted.    This week would like to review the notion of story points.

My change of heart came about when one of my developers Larry Gasik came to me and confronted me about how we treat story points.  Many scrum masters and people in the agile community treat story points as measurements of volume like cups at a coffee shop.  If a developer works six hours a day on code then three story points’ holds up to 18 hours of work or (3*6).  By the same logic a five point story can hold (5*6) or thirty hours of work.

I have been doing it wrong.  A story point is more like a measure of distance rather than volume.  This blog from Mountain Goat Software does a better job explaining this better than I can.  To calculate the “distance” of a story point it is the sum of difficulty and ambiguity rounded up to the nearest number on a Fibonacci sequence.  If I were to write a formula for this it would look like this.

Story Point = Difficulty + Ambiguity
Fn = [Story Point]

Where Fn is a number in a Fibonacci sequence.

Here is where the math gets important.  An Olympic runner can run a mile in under four minutes.  A middle aged man like me can walk that distance in about thirty.  The size of the mile does not change just the ability of the person to cover the distance.  So two people will take a different amount of time to complete a three point story.  So two people will take a different amount of time to complete a three point story.  Now we can use ranges of time.  In the case of three story points, on the low side (3*1) for one hour to complete a story point to eighteen hours or (3*6) on the high side.

This accomplishes three goals.  First, story estimates deal with ambiguity better because the ranges of time get larger as the story point increases in size.  Second the story point allows for better forecasting because developers who concentrate on story points and velocity can plan how much work they can handle in a sustainable fashion.  Finally, saying a story point is a range of time prevents managers and other business folks packing more work into a story point because it is not a fixed volume of hours.

By treating story points like units of distance instead of volume you eliminate numerous distractions in your agile practice.  Managers will not treat sprint estimates like quotations because of ambiguous nature of the amount of time it will take to do the work.  This also prevents a manager from placing more work into a sprint saying, “It was five story points and it only took you 20 hours so I am going to add about ten more hours of work to keep you busy.”

This helped me come up with something I call Kedar’s computation after my technical lead.  Story points also help reduce risk in a project. For instance, say your developers spend six hours a day coding.  The range of hours inside a story point is between one and six.  Following this reasoning three story points could take as little as three hours of work or 18 hours of work.  Now, you have a sprint with 39 story point’s worth of work.  The product backlog items in the sprint could be divided in two ways.  The first way is 13 three point stories.  The other way is three 13 point stories.  Doing a little arithmetic on the back of a napkin this is what you discover.

Given:
13 three point stories.
(3*1)*13 = 39 || (3*6)*13 = 234

Given:
Three 13 point stories
(13*1)*3 = 39 || (13*6)*3 = 234

The amount of hours are the same!  It is pretty cool but here is where you as a scrum master and project manager can say that you have more confidence in getting the work done.  Thirteen point stores are more risky to complete than and three point story and here is why.   Say the developers get stuck on a thirteen point story and fail to deliver it during the sprint.  The math looks like this below.

26/39 which simplifies to 2/3

Now do the same thing for the sprint with 13 three point stories.  The team gets stuck on a three point story.

36/39 which simplifies to 12/13

The team is going to be more satisfied with the work when they deliver 12/13 of the work than 2/3.  Management and the people paying the bills are going to be more forgiving of the team when only 1/13 of the work is incomplete rather than 1/3.

This is Kedar’s computation, which shows that while the work is the same, the risk is much greater for fewer stories with larger story point totals.  To go back to our runner analogy, the runner is completing smaller chunks of the race at a time and is more likely to complete the entire race.  We have a better means of tracking how far along the runner is during the contest.  It may take them a longer or shorter period of time to finish the race but the distance traveled is the same.  The only difference is that it has been divided into smaller laps.

This is why I have changed my mind about story points.  They are more a measure of distance with ranges of time rather than fixed volumes of time.  Making this intellectual shift will make estimating with story points more helpful.

Until next time.


Monday, June 27, 2016

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.