Agile

Recently One80 was asked to provide an estimate to a small startup company. They were looking to build custom software to enhance their existing platform. The company had a nice set of high-level features that they wished to build, had spent some time interviewing potential users, and even had commitments from several to beta test.

With all the due diligence completed, the client was ready to hire someone to build the new platform. They had taken the “build it and they will come” approach.

We came in and reviewed their feature set. We asked a lot of questions about the new custom software, about the problem they were attempting to solve, and the users that they planned to target. It quickly became clear to us that building the entire platform may not be the best path.

One80 reviewed the Lean Start-up approach with the client. We quickly transitioned to the idea of testing the product idea and generating data to help validate the product. We settled on the Wizard of Oz approach.

For those who are not familiar with the Wizard of Oz approach to custom software development, let me explain: Just like the iconic movie, what a user sees is not necessarily the whole picture.

The Wizard of Oz approach validates learning by building a functioning user interface. The user interface is nice and it works, but behind the scenes the process of completing the transaction is done manually.

The business completes the fulfillment of the application manually while tracking data, learning about custom behavior, establishing process, and reviewing potential options.

By completing Lean Start-up testing, the business can validate if the user will actually use the system the way the stated in the interviews and if the new platform will actually solve the users problem.

Is this cheating? NO! It is Learning.

Why spend cash to build a platform that you are not 100% sure will actually solve the problem? By building this small piece of custom software the business can quickly learn and pivot if necessary or continue to build the platform.

Build a partnership with One80 Services, and build the right product. We start by asking the important questions.

Many companies kick off individual projects with specific goals, timelines, budgets and resources. These teams are tasked with a singular focus – clear the backlog and finish the project. They rely heavily on the Product Owner to work with the stakeholders to determine features and priority. They trust that the Product Owner is making the right decisions, and why should they ever question the Product Owner? Scrum indicates that the Product Owner is responsible for the backlog and that the team is responsible or the execution.

Sometimes this is referred to as: Product Owner controls the ‘What’ and the Team controls the ‘How’.

A project is a planned set of interrelated tasks to be executed over a fixed period and within certain cost and other limitations.

This thinking is quickly becoming a limiting factor of organizations that are in highly competitive markets or industries. Companies are finding that thinking in terms of a bunch of horizontal projects instead of vertical products is hindering their ability to adjust to ever shifting customer demands and to drive innovation.

Individual project teams are normally chartered to work set of deliverables. Often these teams work in a limited vacuum blissfully unaware of other projects or company objectives. This approach creates silos that makes it difficult to track and coordinate dependencies. These silos generate gaps in knowledge, skills, and architecture platforms across the organization making it difficult for companies to shift project between teams without huge retooling costs.

The business dictionary has an interesting definition for product under it’s marketing category:

A product is a good or service that most closely meets the requirements of a particular market and yields enough profit to justify its continued existence.

Building a product focused company required a shift in strategic and tactical thinking across the organization. Companies must begin to empower teams to build products and services that meet current customer demand. Teams must be allowed to shift priorities and to begin to innovate to drive customer retention and acquisition.

software that allows them to identify what customer really want, and will retain and attract new customers, what they are will they will pay for.

Allowing a team to become Product focused required change in team dynamics. The Team and Product Owner must begin to develop tools and approaches to developing software that allows them to identify what customer really want, and will retain and attract new customers, what they are will they will pay for. Only when a company makes a shift in this thinking can they start to leverage the software to build a completive advantage.

Every agile book that you pick up discusses the topic of leadership on an agile team. One of the cornerstones of any successful agile implementation is the concept of servant leadership.

Servant leadership was coined by Robert K. Greenleaf in “The Servant as Leader”, an essay that he first published in 1970. The business dictionary defines Servant leaderships as:

Servant leadership stresses the importance of the role a leader plays as the steward of the resources of a business or other organization, and teaches leaders to serve others while still achieving the goals set forth by the business.

In fact, it is hard to imagine a successful team without self organization, accountability, and transparency. Having Scrum Masters, Product Owners, and Managers with servant leader skills can make all the difference on your team’s journey.

If you are interested in applying Servant Leadership skills to agile-specific roles check out our courses page.

In every agile implementation, I am asked, “How will I know who will make a good servant leader?” My answer is always the same, “Everyone can be a servant leader – some people just may have to work at it a little more than others.”

The next question I hear is, “What are the qualities of a servant leader?”

I have devised a simple test to help people identify servant leader qualities:

Step 1

Write down the names of 4 leaders that you admire. These may be people at your current or previous jobs, community leaders, civic leaders, or anyone else that you look up to.

Step 2

Write down 4 qualities that stand out for each of the leaders. When you are done you should have 4 names with 4 qualities for each leader, for a total of 16 qualities.

Step 3

Choose and circle the top 4 qualities you think are the most important in a leader.

BAM! I will bet the top 4 qualities you have chosen are all qualities of a Servant Leader. Each of us already instinctually understands the qualities a Servant Leader must possess. These are qualities we admire in other great leaders.

Each person’s top qualities might be different, and that is ok. This is a personal test to highlight the qualities we find the most important and the same qualities each of us are striving improve upon in our journey to become better leaders.

So the answer to the question, “What are the qualities of a Servant Leader?” is this: You already know what they are, you just need to look at the great leaders around you.

If you would like more information about leadership or to learn how One80 Services can help your company implement a Servant Leadership culture, check out our Agile Leadership or Leadership Conversation courses or contact us for more information.

This is a cheeseburger: This is also a cheeseburger: There are many things you can change about a cheeseburger without causing it to no longer be a cheeseburger: You can change the bun, add some veggies, use whatever kind of cheese you like – and it is still a cheeseburger. But if at some point you decide to stop using cheese, you’ve got a hamburger. If at some point you decide to stop using meat, then you’ve got a cheese sandwich.

As long as key elements are present, you’ve got a cheeseburger. Even if it looks different from the cheeseburger across town.

As long as key elements are present, you’re Agile. Even if it looks different from the Agile across town.

(See where I’m going with this now?) We can vary how we create a cheeseburger, and we can vary how we embrace Agile. The primary reason for this flexibility is this: Agile is not a process. Agile isn’t something you “do”, Agile is something you “become”. You see, as long as you’re embracing the mindset, values, and principles of Agile – you can implement any methodology you choose. You can even use pieces of methodologies and create your own hybrid way of doing things. If you’ve chosen an Agile methodology – like Scrum, XP, or Kanban – but you have not adopted the mindset, values, or principles of Agile: you are not Agile. Just like the cheeseburger, which requires meat, cheese, and bread in order to become a cheeseburger, certain elements must be present before you become Agile.