Answering some questions about Agile Transformation

I was given a set of questions from a consultant working with a company about to begin a transformation to Agile. They asked if I record my answers for their kick-off meeting. That video is above, but I had written my thoughts down as well for clarity, so I am including that text as well.

How hard it can be to implement an agile model in a company where the old model was more hierarchical and conservative?
It can be extremely challenging if only part of the organization is interested in making the change. If the rest of the company are expecting detailed plans and delivery date commitments and the product development team is working with a more iterative approach, that will create a lot of organizational friction. For any agile transformation to be successful, the whole company has to be supportive and committed.

I don’t think that company hierarchy is necessarily an impediment to a successful agile transformation. As long as the responsibilities and expectations of leadership adapt to the new way of working and that leadership is also committed to the agile transformation. Many organizations with more traditional hierarchies build their products successfully with agile methodologies.

What would be your advice for this team to successfully implement the model? What should they be aware of? Basically, the DOs and DONTs.
Do commit to making the transformation, and understand that it won’t be easy. This will be a culture change for your company. Any culture change follows a path where the excitement of making the change is followed by a period where the individuals and teams struggle to understand how to be productive in the new model. During this time (sometimes called the valley of despair), it seems like the best idea would be to go back to the way things used to be. Push through this time and don’t give up. Bit by bit, things will improve, people will figure out how to operate in the new world and you will end up in a much better place.

One of the ways that teams make the transition to agile is to use a known structured methodology like Scrum. At first, the processes and ceremonies will feel strange and not what you understood agile was supposed to be like. Stick with it. As your teams get better at agile thinking, you can start to decide which elements make sense for you and which you may want to change or drop altogether. Each of these things has a purpose, and understanding the purpose and the value when it works well is important before you decide not to do it. Teams that abandon the parts of the process that they don’t like early on often end up with a very poor understanding of agile. They gain very few of the benefits and may be a lot less efficient.

What are the foundational measures they should follow in your opinion?
Like any organizational culture transformation, there should be some time spent by the whole organization understanding why there is a need to make the change, what the expected outcome from the change is and what the plan is. Time should be spent to make sure that all parts of the organization (especially the teams dependent on the team making the change) are committed.

If there is a smaller team that is mostly independent, that team might try to pilot the switch to agile first, to develop some expertise ahead of the rest of the organization and learn from their experience.

What should they anticipate to succeed?
Anticipate that this may be a longer process than they expected, but the effort is worth it! Anticipate that the change may too big for some people to make, and they may choose to leave or try to prevent the change from happening. Anticipate that it will get progressively easier over time.

Other relevant points you might find useful.
I have been working Agile exclusively for almost 20 years after having spent the first 8 years working in a more traditional way. The reason that I have continued to work agile is that I have seen no better way to deliver software efficiently. I am inherently pragmatic. If I saw a better way to work, I would switch immediately. I haven’t found any yet.

The hardest part of adopting agile is learning the agile mindset and understanding that it doesn’t mean abandoning quality, accountability, documentation, process, planning or tracking to deliverables. It is about finding the right amount of each of those things for the project and no more.

In the end adopting agile is adopting a culture of continuous improvement. A culture of always looking for better ways of doing what you are doing. The way we practice agile today is very different from the way that we did it five years ago. Its adaptability is part of its strengths. It’s fluidity also makes it very difficult to learn. It is absolutely worth the effort though.

I wish you the best of luck on your journey!

Slides from my talk on Distributed Teams

Compare the Market was nice enough to invite me to speak at their tech managers’ off-site about distributed teams. This talk reflects my own experience leading distributed teams.

I was presenting to them over video. Their meeting included people in two different offices and also folks dialing in from home. Ironically, in the middle of my talk, I got disconnected from the video conference. Because I was sharing my slides full-screen and had my speaker notes on my second monitor, I didn’t notice. So I spoke to myself for about 15 minutes before I realized what happened and dialed back into the meeting. It was a bit mortifying, but the folks in the UK were extremely nice about it. I can’t think of a better example though of the challenges around working with teams who have to communicate over electronic means constantly, so it was a good illustration of the issues I raised. 🙂

A diversity challenge: tech start-ups have a great opportunity

For decades we’ve been complaining about the lack of diversity in the technology industry. We’ve worked on the pipeline problem. We’ve worked on reducing bias. We’ve worked on the sourcing problem. We’ve worked on the retention problem. The net result thus far is that we’ve barely moved the needle.

Most of the companies that are investing in diversity programs are the larger companies. For them, their continuing lack of diversity is a public embarrassment.

At scale though, it is a far greater challenge for a company like Google, Microsoft, or Facebook to get to any percentage of tech workforce that mirrors their customer base. The numbers are too large to move the needle. It’s far easier for startups.

A critical part of building an inclusive culture that supports diversity is reducing the “otherness.” Inclusiveness is also much harder to do in a large company. If Google hired 1000 developers of color across all their offices, those individuals might never encounter another person like themselves on a daily or weekly basis. They may still be the only person of color that their peers see at work. They will be spread too thinly across the population.

Large technology companies should still work consistently to improve their diversity, but startups are much better suited to solve the diversity problem for the industry as a whole.

A startup with a development team of ten, four of them being women, has a ratio of 40% female developers. Any woman who interviews with the company will see that they are welcome. Any man that interviews will understand that they would be joining a company that takes diversity seriously and will be expected to conduct themselves appropriately. This would be the same for any other underrepresented group. If the company is serious about building a diverse workforce, they will find it easier to continue to be diverse as they grow.

Bringing in a diverse workforce at the early stages of a company will also mean leadership opportunities for those employees as the company grows. It will help address the lack of diversity in industry leadership, which further helps build minority representation. It will also eventually mean more startups started by underrepresented industry groups, which will continue to fuel diversity in the industry. Some of these startups may be acquired, putting their leadership into the leadership of other companies and increasing diversity in those companies as well.

According to most surveys, startup founders’ biggest challenge is hiring development talent. Meanwhile, there are ever-larger numbers of coding schools and boot camps graduating eager junior developers, willing to work hard, and coming from largely underrepresented populations in the industry. There are also many experienced minority developers at the larger companies who would be interested in being in an environment that lets them feel free to be themselves.

Unfortunately, most startups neglect the critical cultural aspects of building their company as they chase product/market fit, funding or customers. What many of them haven’t considered is that building a diverse company will help them find the right product for mainstream audiences, that sources of capital are increasingly valuing diversity in their funding decisions, and that diverse teams build better products that attract more customers.

So, I call on my fellow startup CTOs and CEOs to take on this challenge. If we succeed, we will not only build a better industry; we will also create better companies for our shareholders, our employees, and ourselves.

Talks: 1st half 2017

I’ve been remiss in posting since I’ve been back in Seattle. Readjusting to life in the states, and adjusting to the new role has kept me busy. I hope to rectify that in the future. I have been lucky enough to be invited to speak several times this winter and spring in the US and Europe. If you’ll be there or live nearby and want to meet up, drop me a line on twitter and let me know!

Articles I’ve liked recently (stuff I’ve been reading lately #3)

Why Apple Music Is So Bad When the iPhone Is So Good
On April 28, 2003, Apple launched the iTunes Music Store, saving the music industry from the scourge of piracy while creating a large and steady source of…
http://www.newyorker.com/business/currency/why-apple-music-is-so-bad-when-the-iphone-is-so-good

Scaling Lean — Lean Startup Co. Blog — Medium
Scaling Lean Written by Jennifer Maerz of Lean Startup Co. How can you really measure the effectiveness of your company’s business model? The process goes much…
https://medium.com/lean-startup-co/scaling-lean-d46a52a06fb2#.32bm465po

Silicon Valley’s Scapegoat Complex — Thinkpiece Dot Club
Tech’s Scapegoat Complex T he recent revelation that tech investor Peter Thiel provided the funding for a series of lawsuits against Gawker Media is one of…
https://medium.com/thinkpiece-dot-club/techs-scapegoat-complex-38a4bfb37f22#.b1ckt8ub7

Keep an eye on Norway: Its startup scene is about to go huge
I spent a lot of my formative years in Norway, and have been periodically checking in on the Norwegian startup scene. The first time I went and had a look…
https://techcrunch.com/2016/06/20/norwegian-startup-scene/

‘The Life of Pablo’ and the Death of the Traditional Album
As a genuine certified old person, one who generally doesn’t stream music, who remembers having racks and racks of CDs, and who keeps much of his vinyl sorted…
http://www.complex.com/music/2016/06/kanye-west-life-of-pablo-death-of-traditional-album

If Your CFO Hasn’t Already Told You to Control AWS Costs, He’s About To
You made the obvious move and migrated to Amazon Web Services (AWS). Months later, the attractive glow of the move from CapEx to OpEx spend has been dimmed by…
https://www.linkedin.com/pulse/your-cfo-hasnt-already-told-you-control-aws-costs-hes-jay-chapel

Can Netflix Survive in the New World It Created? – NYTimes.com
One night in early January, a little after 9 o’clock, a dozen Netflix employees gathered in the cavernous Palazzo ballroom of the Venetian in Las Vegas. They…
http://www.nytimes.com/2016/06/19/magazine/can-netflix-survive-in-the-new-world-it-created.html?nytmobile=0&_r=0

Stuff I’ve been reading lately #2

12 Powerful habits I have stolen from ultra-successful people
http://observer.com/2016/03/12-powerful-habits-i-have-stolen-from-ultra-successful-people/ (tip to kate matsudaira)

12 Lessons of Waking Up at 4:30 a.m. for 21 Days — Life Hacks for Business
12 Lessons of Waking Up at 4:30 a.m. for 21 Days If it works for me, maybe it works for you!
https://medium.com/life-hacks-for-business/12-lessons-of-waking-up-at-4-30-a-m-for-21-days-90d1053c3634

Practical Networking Tips for Introverts
Networking was such a foreign concept to me. And I really do mean foreign — we don’t do the organized networking thing in El Salvador. I knew that building…
https://www.ellevatenetwork.com/articles/7282-practical-networking-tips-for-introverts

Curing Our Slack Addiction
I love Slack. I really really do. So much so I would call it an addiction at this point. Slowly but surely this addiction has been killing my sanity and sapping…
https://blog.agilebits.com/2016/04/19/curing-our-slack-addiction/

Official Google Blog – This year’s Founders’ Letter
Every year, Larry and Sergey write a Founders’ Letter to our stockholders updating them with some of our recent highlights and sharing our vision for the…
https://googleblog.blogspot.com/2016/04/this-years-founders-letter.html

The Choice Explosion
Lansing, W.Va. — A few years ago, the social psychologist Sheena Iyengar asked 100 American and Japanese college students to take a piece of paper. On one side,…
http://www.nytimes.com/2016/05/03/opinion/the-choice-explosion.html

Doing a TED Talk: The Full Story – Wait But Why
You’ve probably heard this Seinfeld joke: According to most studies, people’s number one fear is public speaking. Number two is death. Death is number two. Does…
http://waitbutwhy.com/2016/03/doing-a-ted-talk-the-full-story.html

Dropbox cut a bunch of perks and told employees to save more as Silicon Valley startups brace for the cold
You have successfully emailed the post. 20h 8,000 REUTERS/Stringer Winter’s coming in Silicon Valley. When Dropbox employees walked into their new office on…
http://uk.businessinsider.com/cost-cutting-at-dropbox-and-silicon-valley-startups-2016-5

Thoughts on Take Home Interviews
There is a movement now in tech to really think about what it would take to improve our interview process. This is a movement a long time coming. White board…
http://www.elidedbranches.com/2016/05/brief-thoughts-on-take-home-interviews.html

 

A response to the IEEE article: Yahoo’s Engineers Move to Coding Without a Net

http://dilbert.com/strip/1996-07-01

link to the article

First, a disclaimer

Let me start out with the understanding that the article as written is being interpreted through the writer’s own biases and background. I certainly have been misquoted or had a radically different interpretation of my words by an author than was meant.

This is a response to the article as written. I would be happy for someone from Yahoo to let me know if they feel the article was an accurate depiction or not.

Yahoo’s new approach to quality is something many other companies already do

What yahoo learned is what many other companies have learned a long time ago. That segmenting test and development is a bad idea. It leads to developers and testers living in their own silos and playing a blame game on each other. Agile methodologies challenged this idea 16 years ago. Having separate test and development teams is a pretty big red flag for waterfall development.

It wasn’t the fact that there were QA that was the problem

Taking away QA can improve quality to a point because it makes quality everyone’s job, but it won’t get you a high-quality product. You could do that by creating a culture of quality, making everyone feel responsible for quality and keeping the QAs on the teams. You can’t find every bug in the product through test automation. Developers tend to be poor testers of their own code, because they expect it to work and they have a hard time using the product like a non-developer. Having someone on the team with an expertise in quality thinking and a user mindset can do real wonders for product quality.

What Yahoo should try next in their quality evolution

Yahoo could also have increased quality and velocity substantially by keeping the QA, integrating the teams of developers and testers and by creating a culture where everyone feels responsible for the quality of the product. I contend that in their evolution they might yet find another factor increase in these by doing exactly that.