We need to teach the agile reformation

Everyone in agile is an educator. 

I have a love affair with teachers.  My Aunt was a teacher and an elementary school principal.  My first wife was a teacher, and my current romantic partner is a teacher.  I owe my career and success to teachers who invested time and energy on me.  Teachers are the glue which holds society together, and without them, the world would collapse into a puddle of ignorance — teachers mater.

I some respects, I have become a teacher myself. I have spent the last few decades of my life learning software developments and project management.  Now I am sharing my knowledge with others and helping make business better one project at a time.  Being a scrum master and agile coach means you have to be a teacher.  The Agile manifesto and principles of agile are a foundation of a massive ecosystem of learning about how to make work more sustainable, satisfying, and sane.  It is a calling, just like teaching.

The world of agile is continuously changing. After the creation of the agile manifesto, we did not know how to scale agile to larges organizations; software testing was not part of the conversation, and many though it would only work with technology.  Today, thanks to the contributions of thousands of people we have solutions to those challenges.  We use agile in Human Resources, Education, Marketing and Finance.

To me, the reasons are clear why agile is growing.  The emphasis on transparency, inspection, and adaptation prevents organizations from being dogmatic about how they do things.  It is a pragmatic approach which makes an effort to deal with the chaotic nature of the contemporary world.  It is also a world view seen through the lens of engineering, where people fix problems and discover solutions.  Finally, it is an optimistic approach to the world where we make small and steady continuous improvements one sprint at a time.

The agile reformation is not entirely unicorns and glitter.  People are resistant to changes, and large organizations are notoriously hard to transform.  I have suffered numerous personal and professional setback in this field.  Every reformation has a counter-reformation.  Still the hard work and dedication to teaching others how to do things a better way is what keeps the movement going forward.  My love affair with teachers began when I was a child.  The love has grown stronger as I have become a coach in the agile reformation.

Until next time.

Some thoughts on personal change

A typical day for a scrum master; doughnuts and coffee

I have called working in the business world bipolar, toxic and an excuse for mental illness.  I still feel this way, but along the way, I have encountered numerous pockets of decency and professionalism.  I have made plenty of friends along the way.  This week, I took a massive step in my professional career and resigned from my present organization.  I will be joining another firm on November 19th.

When I was growing up in the 1980’s, my parents and teachers spoke about how a career was a pathway or process.  You would join a company and throughout your career advance up the organization.  Your loyalty to the organization came with a measure of job security, and a means to support a family.  I was instructed people succeeded and failed based on individual merit.   The recession of the early 1990’s and over twenty years of being a technology professional have proven those ideas false.

I have spent plenty of time around the damaged, neurotic, and mean people who make up a significant minority of business professionals.  In my worst moments of vulnerability, I have choked back tremendous amounts of rage and bitterness.  In my better moments, I have forced myself to see the good in others.  I was disappointed from time to time, but often my optimism was rewarded.  I leaned on colleagues to muddle through the long days and lack of support, and I relied on my fellow agile coaches who saw something in me I did not.

It is easy to see the bad in the world and wallow in nihilism.  Creating a reformation is going to be hard work.  A modern shareholding company is the closest thing contemporary society has to medieval feudalism, and those in power will do anything to remain in charge.

Fortunately, there are others like me who are agitating for change and a serious business case for making those changes.  Developers, agile coaches, scrum masters, product owners, and random strangers want these changes.  Together, we will work to make the modern corporation more sustainable, sane, and satisfying place to work.  I have spent five years learning to be a great scrum master and coach.  It is now time to put that experience to use expanding the agile reformation. 

Until next time.

Scrum does not have too many meetings

Each reform in society is confronted with a backlash.  The Protestant Reformation spawned the Inquisition.  It is natural that those threatened by it would oppose progress.  It is happening in businesses across the nation with the Agile reformation.  A common objection many have toward agile or scrum is there are too many meetings.  This week I want to discuss agile and meetings.

According to the scrum guide there are four events in scrum, they are:

• Sprint planning
• Daily Scrum or Stand-Up
• Sprint review 
• Sprint retrospective.

In the span of a work week, these meetings should be brief and informative.  A stand-up meeting should take approximately fifteen to thirty minutes.  If it takes longer, you should review how you are facilitating this meeting.  A sprint review is a demonstration to the business users and should take no longer than an hour.  Retrospectives allow a team to inspect and adapt their process.  Typically, this meeting is about sixty to ninety minutes in length.  Finally, there is sprint planning where the development team estimates stories and plans the next race.  Sprint planning can take as little as an hour and as much as six.

Based on this rough estimate we can determine how many hours the agile team is spending in meetings.  Based on a three-week sprint where is how it break down.

• Typical work week 40 x 3 = 120 hrs.
• Standup meeting – 0:15 x 15 = 3:45 hrs.
• Sprint Planning – 6 x 1 = 6 hrs.
• Sprint Review – 1 x 1 = 1 hrs.
• Retrospective – 1 x 1:30 = 1:30 hrs.
• Total Time budgeted in meetings = 12:15 hours of a 120 hrs. sprint.

Thus, a developer at worse case scenario spends just over ten percent of their time in meetings.  The remainder of the time is devoted to writing software and creating value for customers.  It is significantly less than in the world of waterfall project management with its numerous meetings to cover everything from architecture to problem-solving.

The scrum master and product owner spend their time in meetings, but it is to protect the team from being distracted from delivering value.  It is why I attend meetings about I.T. governance or architecture so that my team does not have to.  It is why the product owner is answering customer inquiries and meeting management.  We attend the meetings so the development team can concentrate on what is important which is shipping code.

It is why I find the argument that agile has too many meetings disingenuous.  People who are opposed to agile are not opposed to the meetings they are opposed to the routine nature of the meetings and the expectation to ship working code at the end of each sprint.  Transparency of this nature quickly exposes the unwilling, incompetent, or invisible people in an organization who do not deliver value.  When we discover these individuals, it creates a backlash in the organization.

So, scrum and agile does not spend too much time in meetings; it concentrated on what is essential.  An agile team’s first and foremost duty is to deliver value to the business; anything else is waste.  I am looking forward to hearing from you and knowing what you have to say.

Until next time.

This reformation may take a while

Progress takes time.
  Image courtesy of Pawel Jonca.

The history of progress and social change is rocky.  The first feminists from the Seneca Falls convention did not live to see the passage of the women’s suffrage.  Women would continue to struggle for equal rights and acceptance outside the home and today women in technology face the soft misanthropy of “Brogramer” culture.  It is discouraging that each step forward leads to another pushback from people who feel threatened by that change.  It has been on my mind as I see businesses struggle with accepting the agile reformation sweeping business. 

Like many technology professionals, I receive e-mail messages daily from recruiters.   These individuals want me to sell my home and relocate to remote parts of the country for six to twelve-month contracts.  I ignore these messages politely or reply that I am not interested in relocation.  This week I receive a notice for a “scrum-project manager.”  I was intrigued.  I glanced at the requirements, and this is what I found. 

• Two to three years’ experience in SCRUM
• Two to three years’ experience as a BA/Project manager.
• One or more years of Experience in JIRA.
• Great Communicator.
• Organized.
• Salary 50k to 75K

I did a double take and then attempted to unpack this request.  According to the Scrum guide, there are only three roles; developers, a product owner, and scrum master.  There is no mention of a project manager.  Agile and Scrum according to the manifesto put, “Individuals and interactions over process and tools.”  I appreciate the author of the job post understands that communication skills and organization are not optional for a scrum master.  Finally, the salary requirements are laughable and way below the $100,000 national median compensation stated in LinkedIn.  For a company attempting to adopt agile, this is not a credible offer.

The person who wrote this job requirement should be embarrassed.  The salary is in the lowest percentile quarter of prevailing wages.  The author does not understand the role of a scrum master, and they confuse agile experience with project management.  Anyone who is thinking about this role should reconsider.  It will stunt your career growth, and the company appears to be paying lip service to Agile.

It is my hope businesses will do a better job writing these requirements and recruiting proper agile talent.  Unfortunately, this means executives and human resources professionals still have a long way to go before they understand agile and what it takes to be a twenty-first-century company.  Just like the feminists of Seneca Falls, after seeing job requirements like this, I am afraid that I may not live to see that change.

Until next time.

It is worth it!

The work is worth it.

I have been doing plenty of reflection.  I blame the dispiriting winter season in my hometown of Chicago.  The cold winter nights force you to confront your past and ponder your purpose.  My friends and social media contacts are asking me plenty of questions about my weird profession.  These kinds of existential moments make me want to do a little explaining.

I joined the agile reformation in 2009.  I was working as a contractor for a family run medical supply company.  I was thoroughly miserable.  I had no job security and little hope. I spent each day grinding out code for capricious people who treated everyone not family as medieval peasants.   Family disputes would boil over on to the sales floor, and anyone caught in the crossfire could lose their job.  It was such a dispiriting place to work.  I witnessed the ten-year-old grandson of the founder tease a salesperson saying, “Daddy says you are fired.”

In the middle of this night of the soul, a project manager decided the team should try “agile.”  It began with daily stand-ups and doing releases in two-week chunks.  It ended with unemployment.  The project manager left for a better job.  The IT Director realized I had more credentials than he did so I was a threat, and it made me expendable.

Between job searches, I did research and the more I learned about Agile, the more I realized it was a better way to lead software projects.  I also realized that the concepts while simple to explain were hard to implement.  Thanks to the Agile Manifesto and the early proponents of the scrum, there was a way to perform technology work without abusing people and providing better value to the business.  I would spend the next four years as a developer spreading the word about this new approach.

Things finally came to a head when I left my last role as a senior developer and became a scrum master full time.  I was no longer some developer mentoring others.  I was leading other teams and setting an example.  I thought I was ready.  I was wrong.  Over the last five years, I have been tested and challenge in numerous ways.  I have succeeded in public ways and failed in equally public fashion.  I am not the scrum master I was five years ago.  Everything I have learned along the way has made me better.

I keep thinking about a quotation from Dave Burgess I tweeted out last week.

"It is not supposed to be easy- its supposed to be worth it!" Nice wisdom for scrum master from #tlap #agile #leadership

— (((Ed Wisniowski))) (@eeeThree_ed) February 13, 2018

The last nine years of my agile journey have been challenging, but it has been worth it.  I am a better leader.  I am a better developer.  The software is getting shipped on time, and the office is a little less capricious.  I do not have entitled ten-year old’s threatening to fire me, and the business community seems to be catching up to my way of thinking. 

This hard journey is probably worth it, and I am proud to be sharing it with you.

Until next time.

Eat up

I feel like a shark!  "Chomp!"

Social movements and organizational change are difficult to measure, and it is particularly hard to do in the world of business.  The business press concentrates on investing and accounting.  Since the beginning of the agile reformation, those of us involved in the change have openly wondered if we are making an actual difference.  As 2018 begins, it looks like agile is becoming mainstream and successful.

In 2011 a famous editorial appeared in the Wall Street Journal, It was titled, “Software is eating the World.”  The principal thesis was for companies to succeed they have to behave more like software companies.  It was a daring argument.   The seven years which followed have vindicated that notion.  Google, Tesla, Amazon and a funny project called Bitcoin are dominating headlines and the business community.

Tesla is still struggling to meet its production commitments and Bitcoin, to me, feels like a blue sky stock but what all of these firms have in common is a willingness to innovate, iterate, and move fast to satisfy customer demand.  Even companies who lost their way are embracing blockchain technologies, cloud computing, and rapid software development. 

It is satisfying to know that my career choices have mirrored changes in the business.  While business is changing business leadership is struggling to keep up.  Organizations charts still matter in many places.  Command and control measures which existed for years are difficult to discard, and inertia prevents most organizational change.

It has created a quandary and spawned an entire industry of coaching and consultants, who are attempting to show others how to do business with the agile paradigm.  What these coaches discover, is a business is a social construct along with a business entity.  The ego of a director may be more important than the needs of the company.  Board members excuse a lousy quarter because they golf with executives.  Whole industries condoned sexual harassment and assault as long as the abusers generated revenue.  

Which is why I find the turnaround at Microsoft so fascinating.  They went from a sales culture under Steve Balmer to an engineering culture under Satya Nadella.  After product failures like Zune, Vista, and Windows Phone, the organization decided to place its future in the hands of a software engineer who felt building better products was the path to commercial success.  It is a gamble which has paid off handsomely.

Microsoft has embraced Agile, and it is paying enormous dividends.  That is why this week an article appeared in Forbes called, “Agile is eating the World.”  The reformation is growing, and the success is getting noticed.  It is a satisfying development to me.  I am no longer a lonely missionary in the wilderness, but a professional at the table is making a difference.  It is nice to see the times change.

Until next time.

Agile is about Deadlines

I have nothing on Martin Luther
but I know a little about software development.

Five hundred years ago a German monk named Martin Luther hammered 95 theses to a church door.  He was calling attention to corruption inside the Catholic Church and started the events which created the protestant reformation.  The agile manifesto is only sixteen years old, but it has produced a transformation in the business world.  I consider myself one of the evangelists spreading the word.  With every reformation, there is a counter-reformation, and today I would like to discuss one of the principle objections used by opponents of agile.

There is an excellent blog post written by the Wall Street Journal called “9 Myths About Agile.”  I strongly recommend it.  One of the most durable myths about Agile is the preconception that deadlines do not matter. Work gets completed, and deadlines are not necessary.  I wish to argue that deadlines are an essential part of the agile process and provide an example of how it works.

The most central feature of Agile and Scrum is the time box of the sprint.  For two to four weeks, the development team completes goals.  If they do not finish the stories in that period, then the sprint is considered a failure.  Failure is not a bad thing it is a learning opportunity for the team can to do better next time. Scrum relies on deadlines to focus effort and drive improvement.

Skeptics would then argue that sprints are well and good, but there are not firm due dates to communicate to upper management or the people paying for the work.  My reply is that with a sprint backlog following Roman Pichler’s DEEP model, it is easy to forecast when work will get completed.  The backlog is detailed to show the volume of work.   The backlog is estimated because it allows the product owner and the business to predict when work will get done.  The backlog is emergent so it can adjust to changing conditions as a project moves forward.  Finally, prioritization allows the firm to say what matters and what does not.

I am now going to provide a simple example.  The marketing department needs to incorporate social media into its website.   The works need to be accomplished by November 1st. The product owner gets to work, and come up with a list of features.  It should look like this:

• Milestone: Social media on corporate website (Due Nov 1st)
  • Feature: Facebook
  • Feature: Google+
  • Feature: Twitter
  • Feature: Pinterest

Now it is up to the Product Owner and development team to write stories.  After a week or two of effort the backlog looks like the following:

• Milestone: Social media on corporate website (Due Nov 1st)
  • Feature: Facebook
    • Set up a Facebook account.
    • Create Hooks into Facebook API.
    • UI for Social media on the page.
    • Create log internally when pages are shared.
  • Feature: Google+
    • Set up Google+ corporate account.
    • User Google tools to allow sharing of stories from the website.
    • UI for Social media on the Page.
    • Create log internally when pages and shared.
  • Feature: Twitter
    • Set up a corporate Twitter account.
    • Use Twitter API to post content.
    • UI for Social media.
    • Create log internally when pages are shared.
  • Feature: Pinterest
    • Set up corporate Pinterest account.
    • UI for Social media.
    • [Spike] prototype how to use Pinterest API.
    • Create a log when pages are shared.

The backlog looks typical to a scrum master or anyone on a development team.  The Vice President might understand what the group plans to do. The group estimates with story points because business people treat hours estimates as quotations of work.

• Milestone: Social media on corporate website (Due Nov 1st)
  • Feature: Facebook
    • Set up a Facebook account. - 2
    • Create Hooks into Facebook API. - 3
    • UI for Social media on the page. - 3
    • Create log internally when pages are shared. - 13
  • Feature: Google+
    • Set up Google+ corporate account. - 2
    • User Google tools to allow sharing of stories from the website.- 3
    • UI for Social media on the Page. - 3
    • Create log internally when pages and shared. - 13
  • Feature: Twitter
    • Set up a corporate Twitter account. - 2
    • Use Twitter API to post content. - 3
    • UI for Social media. - 3
    • Create log internally when pages are shared. - 13
  • Feature: Pinterest
    • Set up the corporate Pinterest account. - 3
    • UI for Social media. - 3
    • [Spike] prototype how to use Pinterest API. - 8
    • Create a log when pages are shared. - 13

The estimates from the team point out severe risk and ambiguity.  Also, the team has not worked with Pinterest, so they are going to do some experiments to understand how it works.  The sponsor of the product might get frustrated at this point and ask, “When will it be done? Can I have it by November 1st?”

The scrum master should be able to answer that question.  According to the backlog, there are roughly 91 story points of work.  The team can do 21 story points a sprint and each sprint is three weeks long.  It will take roughly twelve weeks to do the job. It is good news if it is June but bad news if it is September.

So a process of negotiation begins where stories get prioritized, and others ignored.  If the company sells food products, Pinterest may be more critical than Google+.  A media company which relies on breaking news might ignore Pinterest and focus on Twitter.  The product owner might notice that each social media site has its analytics suite and that an internal log is not necessary.  Fifty-two story points fall off the board.  We have 39 story points of work which we can get done in two sprints or six weeks.  If we begin in August, we will hit our due date.  The final board looks like this:

• Milestone: Social media on corporate website (Due Nov 1st)
  • Feature: Facebook
    • Set up a Facebook account. - 2
    • Create Hooks into Facebook API. - 3
    • UI for Social media on the page. - 3
  • Feature: Google+
    • Set up Google+ corporate account. - 2
    • User Google tools to allow sharing of stories from the website.- 3
    • UI for Social media on the Page. - 3
  • Feature: Twitter
    • Set up a corporate Twitter account. - 2
    • Use Twitter API to post content. - 3
    • UI for Social media. - 3
  • Feature: Pinterest
    • Set up the corporate Pinterest account. - 3
    • UI for Social media. - 3
    • [Spike] prototype how to use Pinterest API. - 8

So in this brief and simple example, I have shown there is a quantitative and drama free fashion to discuss projects where deliverables get negotiated, and deadlines get met.   Agile and Scrum can help people make educated decisions about what work can get done and when it will get done.  All that is required is a conscientious product owner, a dedicated development team, and a scrum master who will speak the truth to decision makers.

Agile is about deadlines, and I am willing to put my career at risk to prove it; just like that German Monk from five centuries ago.

Until next time.

Beware the Temptation of "Dark Scrum"

Avoid the temptations of "Dark Scrum"

I have been an agilist since 2009.  I began collecting certifications for Agile and Scrum since 2013.  I even finished up my master’s degree studying the differences between waterfall and iterative project management processes.  I have some skills.  What I find most challenging as an agile practitioner is a disconnect between those of us doing the work and the business people who depend on us.  When this happens, it creates a situation Ron Jeffries calls, “Dark Scrum.”  As a scrum master and agile coach, it is your duty to avoid this situation.  This week on the blog avoiding the temptations of “dark scrum.”

In my formulation, "dark scrum," is when the business users of Scrum use the methodology to enforce control over software development rather than use it to improve quality and customer satisfaction.  Jefferies gives plenty of good examples on his blog, but I would like to provide two more.  I consider them to be pathologies of a dysfunctional organization.

Dark scrum pathology – shoehorning arbitrary deadlines on to sprints.  

One afternoon, I was in the office of a Vice President.  I had been raising concerns with him that a project was going poorly and that I would need his support and intervention.  The meeting did not go well.

“I promised the board that this project would be done by X date,” he said.

I told him based on the stories we had and a three-week sprint cadence we could deliver by a later date.

“You are agile, figure it out,” the VP said, “I need it by X date.”

The executive violated the social compact of agile, and we removed stories and features to meet the arbitrary date.  The customer was disappointed, and the Vice President looked bad.

Dark scrum pathology – why do I have to meet with the off-shore team.

Product owners write stories, but because of the time difference between the onshore and offshore components of the project, did not participate in the stand-up meetings.  We had created a situation where the developers would ask questions, and it would take over 24 hours to get them answered.  Product owners also complained that the team was not understanding the detailed requirements to get the work done.  When prodded to attend the stand-up call with the off-shore team a product owner indignantly said, “I am not waking up that early to talk with India!”

We were able to correct these pathologies.

To address the arbitrary deadline problem, bring in executives and product owners to level set expectations.  In the world of Scrum, the product owner is the person primarily responsible for the success or failure of a project.  The executives outside the team are responsible for funding and helping to remove organizational obstacles.  Knowing financing and deadline commitments provides the product owner a framework to write stories.  The scrum master can then use team velocity and the sprint cadence to let everyone know when a deadline is realistic and when it is not.  This way the social compact of agile is respected, and there are not secrets for all the parties involved.

We solved the next pathology by moving up the stand-up meeting by thirty minutes.  The product owner could take the call from home when they got out of bed but before they came into the office.  Product owners answered questions quickly and user stories improved.  Also, automated testing got better as product owners relied on the offshore QA professionals to streamline acceptance testing.  What was once a burden, became a win-win for the entire team.

The hard part about being a scrum master and agile coach is you are forced to come up with solutions like this each day to prevent your organization from falling into “dark scrum.”  Any situation where those in power ignore the input of the people doing the work is going to add darkness to the organization.  It is why the agile reformation is so important.  By beating back the pathologies of “dark scrum,” we can be successful software developers and professionals.

Until next time.

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.

History is NOT over! It is just beginning.

Not the same person who graduated from ISU.

It is a special anniversary of sorts.  Twenty-five years ago I walked commencement for my undergraduate degree from Illinois State University.  Five years ago, I received my Masters in Management from University of St. Francis.  I am very proud of those accomplishments but I confess what I gained from those educational journeys was not what I expected.  The web site LinkedIn has gotten into the act by having its major authors talk about what their current selves would tell their freshly scrubbed 22 year old selves graduating from college.  This week I don’t want to share advice but rather illustrate the radical changes which have taken place in the last 25 years.

Putting things in perspective, my senior year of college, was supposed to be “the end of history.”  The Berlin Wall had fallen.  Communism was in retreat.  The economy was in a downturn but we would not know how bad it was going to be until the college canceled the job fair.  Microsoft had just released widows 2.0 to the market place.  That did not matter to most of us college kids we had MS-DOS personal computers or Apple II computers to do our work.  The phone system in the dorms was so bad that we could not hook up a modem because each room did not have an individual line.  We were on party lines where if someone picked up a phone in another room it would disconnect the modem.  Silicon Valley made semi-conductors and not millions of start-up dollars.  Mark Zuckerberg was a six year old.

That was the world I graduated into.  My brilliant career in radio lasted 18 months and then I drifted around in retail and the casino business before finding my way at the age of thirty working my first entry level job as a Visual Basic programmer.  Over the last seventeen years, I have seen trends come and go.  I have witnessed the giddy and stupid days of the dot-com bubble.  I suffered through the economic downturn of the post 9/11 economy.  I saw the birth of Windows 95 and the flop of Vista.  I watched Microsoft transform from a smug master of the universe to the technical power house which wants to be loved.  All of this in my lifetime.

I think the most important thing I have witnessed is the birth and spread of the Agile Reformation.  It began innocuously enough with top project managers getting together at a ski lodge and to share ideas.  It ended with the agile manifesto.  Now fourteen years later, I consider myself to be a missionary of sorts spreading the word and trying to make business a little less oppressive.  Sometimes I feel like I am tilting at windmills and other times I earn a little victory.  As a whole, I am trying to change a business culture one step at a time.  I am also trying to build my own business at the same time.

I don’t think I could give any advice to my 22 year old self.  I doubt he would believe all the missteps failures and misfortunes he would experience would lead to the life I currently have.  I find it surprising myself.  At 22, I was going to be a disc jockey to rule the world instead I became a missionary quietly leading change in global business.  The future belongs to misfits like me and other innovative individuals who want to change the world.  I am glad you are along for the ride.

Until next time.

The Agile Reformation coming to a cubicle near you.

Agile is just another Reformation
Martin Luther has nothing on us.

I am going to be missing the fun and excitement of the Scrum Gathering in Phoenix this week.  I am a little disappointed about this but it gives me an opportunity to concentrate on some changes taking place at my office and at my home business.  It looks like the unveiling of my Ninja Lion Sensei Master Cobra T-shirt will have to wait another year.  This week I want to talk about change and innovation.

I have been reading a fantastic book by James Burke called, “The Day the Universe Changed.”  In it, he talks about the changes in science and technology which caused the historical, political, and social change in Western civilization.  What strikes me most about the reading is how someone at certain points of history someone said, “this is not working!” and they went about finding ways of thinking that would work.  If it was not for this kind of exasperation with the status quo, I doubt we would have such modern innovations as germ theory, global telecommunications, and Snapchat.

Kidding aside, I think we are in the midst of another one of these flux points which Burke was so good pointing out.  I call it the Agile Reformation.   Since the fall of the Berlin wall and the spread of neo-liberal economics, there have been numerous counter movements to this “End of History.”  Unfortunately, many of these counter-movements have been backward-looking drawing on Communism, Socialism, and religious fundamentalism.  Agile with its focus on improvement, sustainability, and collaboration seems like a positive direction for the twenty-first century and I am glad that I am part of this movement.

This seems very pie in the sky but please hear me out.  We are confronted with numerous problems in Western Civilization.  Income inequity, climate change, pollution, and racial unrest are social and technological problems which are solvable.  The dreary nature of working for a modern corporation is solvable.  They are solvable because in a world of seven billion people there are plenty of smart folks who want to solve these problems.  This is where Agile comes in.  The principles of agile and the agile manifesto act as a framework for problem-solving.

I am very proud to be part of this way of thinking and leading change within my organization.  It is not going to be easy but if we do it correctly we can institute amazing changes and reforms one iteration at a time.  I hope you are with me on this.

Until next time.