Beginning with the first three habits of independence and then the second three habits of interdependence, we have gradually explored the musings of Stephen R. Covey from “The 7 Habits of Highly Effective People” as it relates to agile transformation.  Now, we conclude this series with the all-encompassing Habit 7 – Sharpen the Saw, otherwise referred to as the principles of balanced self-renewal.  All-encompassing because Habit 7 truly encompasses all the prior habits towards continuous balanced renewal.  Covey declares Habit 7 as the habit that makes all the other habits possible.

READ ON

Habit 6 – Synergize, in our exploration of Stephen R. Covey’s “The 7 Habits of Highly Effective People”, is quite significant when it comes to effective agile transformation. This habit, considered the “principles of creative cooperation” by Covey, is the culmination of all the prior Habits 1 through 5.   As we’ve seen, each habit builds upon the last, and now with Habit 6, we are at the peak of what it takes to be highly effective.

Covey emphasizes that done right, Habit 6 can produce extraordinary results by producing new alternatives never before considered.  He offers up a simple meaning to what it means to synergize.

“The whole is greater than the sum of its parts. One plus one equals three or more.”

READ ON

We are 4 down and 3 to go in our exploration of Stephen R. Covey’s book, The 7 Habits of Highly Effective People, with regard to effective Agile Transformation. Our focus this time is Habit 5 – Seek First To Understand, Then To Be Understood. Quite frankly, Habit 5 is the answer to Habit 4 – Think Win/Win or rather, seeking first to understand makes Win/Win possible.   

Habit 5 centers around the highest form of listening, what is referred to as “empathic listening.” With this Habit, Covey challenges us to develop the powerful skill of empathetic listening to first diagnose, seek to deeply understand, before prescribing a fix to the problem.   

READ ON

We are at the midway point in our Agile Transformation-focused exploration of Stephen R. Covey’s “The 7 Habits of Highly Effective People” with Habit 4 – Think Win/Win. I’m sure we’ve all said it in business and even relationships, but how does Covey intend it towards being highly effective and what does it mean to an Agile Transformation?

Before we explore the answer to that question, it seems appropriate for a quick refresher on the first three habits. Habit 1 – Be Proactive, and Habit 2 – Begin With The End In Mind ultimately enable Habit 3 – Put First Things First. In terms of what we’re here to talk about, an organization that is proactive (Habit 1) with an end state vision (Habit 2) and realizes it through a focus on what’s most important (Habit 3), is well on their way towards effective Agile Transformation. With that, let’s now consider Habit 4 – Think Win/Win.

READ ON

Last time we explored Habit 2 – Begin With The End In Mind of Stephen R. Covey’s “The 7 Habits of Highly Effective People” as it relates to Agile Transformation.  With Habit 2, we concluded that it’s essential for an organization to begin with the end in mind, their end state vision, for an Agile Transformation to be successful and that they must be proactive (Habit 1) in support of that. This time we’ll explore Habit 3 – Put First Things First for which Covey considers the fulfillment of Habits 1 and 2. 

READ ON

Two years ago this month Catalina went full bore, head first into Agile, applying the Scrum methodology, to deliver and execute on the top priorities of the company.  Now, two years later, we continue to embrace and uphold the Agile values and principles.

We’ve made it all the way to Sprint 53, but who’s counting?  In fact, you might think of us as Baby Yoda right now.  In the past two years, Catalina has delivered thousands of valuable stories to our stakeholders including retailers, CPGs, and corporate.  We continue to scale Agile up and across our enterprise.  And, we’ve got our senior leadership team applying Kanban at the portfolio level to manage Portfolio Epics as part of our Agile Portfolio Management process.

While we are at the end of our transformation, we are only at the beginning of our journey.  As we begin to roll (or shall we say sprint) into year 3 of our Agile journey, we continue to work towards being a truly Agile enterprise.  The cultural change to be an Agile enterprise is constantly a work in progress and the journey never really ends.  Each day, we just try to be a little more agile than we were the day before.

I am very pleased to introduce guest blogger, Toby Morris, for this latest post.  Toby, known around these parts as “The Amazing Toby”, is a software developer at Valpak.  Toby has been with Valpak for many years and has had the opportunity to experience our Agile transformation from the trenches, as the title of this post suggests.  Toby gives a (sometimes brutally) honest and extremely insightful perspective on Agile.  Enjoy!

Over the past year, this blog has chronicled the Agile transformation of a company from the viewpoint of a self-professed “Agile enthusiast”. So, you have to take those posts with a grain of salt. Of course she’s going to have a relatively rosy version of things, seeing the big picture, seeing how upper management reacts to the change, seeing how the new practices is affecting the quality and quantity of product being produced. But one of Agile’s tenants is people over processes. So to truly judge the success and impact of Agile on a company, you have to get in the trenches and see how those changes are impacting the grunts. From the viewpoint of a grunt, I’m pleased with the change.

To show how things have changed, I have to tell you how they were. Just prior to our Agile transformation, we had several problems as a department. Morale was pretty low, and people were fairly unhappy with their jobs. Our department held a series of meetings to try and find the root of this dissatisfaction. After a few talks, some common themes emerged.

Most technical workers in the department had a director, a manager, and sometimes a lead. Most worked on multiple project teams, and each project team had at least one Project Manager. Each Project Manager considered their projects and tasks to be the highest priority for their teams. People were being pulled apart by competing PMs.

Another common issue was unrealistic expectations for project performance. We frequently worked on projects that were breaking new ground, but were required to make estimates that were little more than wild guesses, and we were held to them. If we “guessed” it would take six months to learn and implement a new technology, but it actually took eight or nine months, we would fail, leaving a shattered trail of disappointed business people and angry project managers.

Along with the missed deadlines, the business was becoming concerned about our ability to deliver quality products in reasonable amounts of time. We constantly ran over, and with every looming deadline, overtime pushes, sometimes all night and all weekend long, were the norm.

When the big leap was announced, there was a lot of skepticism. We were in a very sore spot, and now someone wanted to move our cheese. They actually wanted to replace our cheese with some type of healthy, new age vegetable, and we were scared. We were confused. There was a great deal of apprehension. How could we do everything we’ve been doing in a tried and true Waterfall world in short, little two-week sprints? And even if we could do it, why bother? Would it really make a difference?

Yes, it did.

We went from having multiple overseers to overseeing ourselves. We had one person determining what we’d work on, and we would decide how we did it. We broke big, multi-month projects into small, two-week stories. Some teams even broke them down smaller, opting to work in simulated one-week sprints.

It wasn’t easy to change. We all had to move, physically, to be closer to our teams. And we lost our walls. We moved into more collaborative cube setups. This provided a much more significant benefit than imagined. Sure, we could communicate readily now. No more emails or phone calls. No more standing up and walking across the room to ask a simple question. We could now turn, get the person’s attention and get our answer in seconds. Sure we could more easily collaborate. Having the developer sitting next to the QA, or the front tier, middle tier and back-end guy sitting next to each other, we could make changes and fixes in minutes rather than hours. But the real benefit is camaraderie. These people that we self-organize with become more like friends than just co-workers. A true sense of team starts up, and before you know it, you’re working together more efficiently.

We also had to learn new words and principles and practices. We learned how to effectively scrum each morning. We learned how to write user stories, and break them into actionable tasks. We even got yellow penalty flags to throw at others when they slipped up and let some waterfall back in.

We had a lot of changes.

But we got more benefit from those changes than imagined. Working in small, self-organizing teams, with a single product owner determining what we were working on for the next two weeks made all the difference. No longer did we have ambiguously ranked priorities. We knew exactly what needed to be done first, second and third. No more were we getting constant interruptions and additional tasks from various project managers. What we have to work on at the start of the sprint is what we’re working on for the whole sprint, and heaven help the person that tries to add a user story mid-sprint.

By our second sprint the business had already noticed and welcomed the new process. Instead of waiting months to see anything tangible, and to find out a project would be delayed even further for obscure, incomprehensible technical reasons, they were now seeing incremental upgrades to existing apps and new features being added to new apps on a bi-weekly basis. And even better, their feedback was incorporated into the rapidly evolving applications they depend on. They were helping to shape the tools they use.

Having a business person intimately connected to each technical team also opened the top secret technical world up and exposed our black magic. We gave our product owner an understanding of the whys and hows of software development. There were no longer the “we’re unable to do that for technical reasons”. Now, we would tell him that the protocol we’re using doesn’t support that level of encryption, and that we’d need to re-engineer the system to use a different API to achieve his needs. And that it would take another sprint to discover what that would require. And he would understand what we’re saying, why it’s causing a delay, how long the delay will be and ways to work around it. The smaller tasks and user stories mean smaller and easily recoverable failures.

Collaborative and adaptive. That’s how we work now. Morale from a technical worker standpoint has significantly improved. Our products are visibly more stable, bug-free, and valuable. Our business teams are now part of the team, and believe in our ability to make their jobs easier. We are no longer adversaries. We are agile, not hostile.