Archives for 17 Jan,2017

You are browsing the site archives by date.


Press: Agile Implementation

Agile implementation trends have changed, as we inspect and adapt.

I was recently interviewed for an article in the Midlands Business Journal’s technology section as a contributor to their technology trends overview.  Here are some snippets from that conversation:

MBJ: What do you think our business-owner readers should most know in the 2016 version of this annual section, as it relates to technologies or industry developments of interest?

In the past during Agile implementation, companies were more apt to start with one Agile methodology and then later experiment by adding pieces of other methodologies.  As Agile becomes more understood as a set of values and principles vs just a process or set of processes, we see a trend toward mixing Agile methodologies from the beginning of an initiative.  

At One80 Services, we see a lot of companies begin their Agile journey with perhaps a basic Scrum framework, incorporating aspects of Kanban and XP into their process right away, rather than waiting a year or more to experiment with combined methodologies.

It’s encouraging to see this trend, as people become more and more familiar with the basic principles and values that Agile exists to sustain.

MBJ: What are some examples of memorable current or recently-completed projects or initiatives your team has taken on, which illustrate some of the aforementioned technologies, approaches to solutions, or broad industry developments?

One80 Services is currently working with several clients in highly competitive industries. Each client is hoping to complete a number of projects in the next 12 to 18 months in order to satisfy customer demand. The projects address a range of clients goals including project visibility, improving ROI, strategic planning, capacity planning, collaboration and accountability, and others. 

Agile puts individuals and interactions above processes and tools – meaning that how things are working for you is always more important than which process you choose. We customize solutions to each client, and in some cases even to each team. 

This means that in one company, we may have several different teams implementing different pieces of varying methodologies. One80’s clients are delighted and often surprised by the flexibility that exists within an Agile framework.

MBJ: What would you describe as the biggest 2 to 3 changes in the 6 months to a year, as it relates to some of the aforementioned products, solutions, and approaches?

As mentioned previously, One80 Services has been working with clients on multi-methodology approaches from the beginning of their Agile implementation.  This is a change from how we and others in our industry would previously implement Agile. Rather than teaching a course about pure Scrum, we now go in and show a mix of methodologies that would work best for each client’s specific needs.  People are really open to using pieces of several methodologies together when they see how well it fits their situation. 

Coming at Agile training from this angle makes it imperative to begin with a conversation. It’s really important to understand the dynamics of the organization and the projects involved – how the teams are formed, what they are focused on, and what challenges they face – before a process is created.

At One80 Services we call this an Agile Kickstart. It’s a conversation followed by training and backed by coaching. This seems to be a magic potion for Agile success.

Really understanding the needs of the company, the team, and the customer before an Agile implementation is key.   Many Agile failures are caused by a lack of understanding or upfront planning.

MBJ: What are the implications of the changes highlighted in the preceding question for our employer-readers?

The competitive edge of Agile development has been proven over and over again.  A willingness to blend methodologies to create the best possible process for your project is the best way to achieve Agile success.  

You can achieve improvement in a variety of areas such as better, empowered, self-organizing teams; a greater focus on delivering value to your customers; faster project delivery times; and improved overall company culture.

If your outsource partner doesn’t use Agile, consider contacting One80 to see how our expertise can help your company to achieve its goals.

Contact us today.


Scrum Does Not Have a “Sprint Zero”

Sprint Zero:  Sprint Zero is the time used to plan and set-up the foundation needed before a team can execute their first successful iteration. Sprint Zero deliverables may include: identify stakeholders, build the team, training, create high-level architecture diagrams, and set-up environments.

It’s become quite common for Scrum teams to begin by planning Sprint Zero. I’m not sure if you’re aware, but Sprint Zero is a bit of a debate topic at times.  I’m often asked what my stance is when it comes to Sprint Zero, and I struggle a bit since the real answer is this:  it depends.

I know it seems like answering with “it depends” is totally punting and not helpful. However, up-front pre-implementation activities vary greatly depending on what is being built.

1) Large Mission Critical Enterprise Applications

Assuming this is creating something that didn’t exist before, or re-building something that is legacy, I would start with a small core group of “key” people. An enterprise architect, a business leader (Product Owner, perhaps) – the person who owns the vision of “why” we are doing this, possibly some key stakeholders, etc. Ideally no more than 5 people. In this case, this small core group would determine the answers to the questions you ask and then figure out the best way to execute.

Activities would include: determine how to and then get started on setting up environments, technology, CI strategy, training, change management, etc. This small team would also come up with a strategy on how to assemble Agile teams.

I would not call this a sprint zero. As has been said before, it’s not a sprint as defined by Scrum, so let’s not pretend it is.

2) Small – Medium Projects Using Existing Technology

As you all know, these come and go. This is the steady stream of new feature requests that come from the business. It may take just a couple sprints to deliver, or it may take 10 sprints. The number of sprints is irrelevant in this case. There is still no need for a sprint zero. Just spend some time creating the product backlog and start. Business as usual.

3) New Product or Start-up

I have been involved in quite a few start-up ventures as a Scrum Master or as a developer. We start small with a vision (that’s typically been baking for some time) and a quick technology conversation, then we start executing. We have passionate people who all are trying to achieve the same goal. Yes there’s “up front” stuff, but it’s super quick…as in hours. In no way would I consider it a sprint zero.

Ultimately, I would love to eliminate the term “sprint zero” from our nomenclature. Upfront activities (other than release planning) should only be reserved for contexts where complexity, breadth of impact to the enterprise, and cost are all high.

For agile training check out our list of courseware, we would enjoy helping you on your agile journey.

Contact us today


post =