Ade Shokoya has interviewed some of the industry's leading agile experts, and we got the chance to interview Ade himself about the current relationship between agile and lean and the challenges and rewards of being a ScrumMaster in today's software world.
Ade Shokoya is a certified ScrumMaster, Business Analyst, Agile Consultant, and the founder of Agile TV. His years of experience working on large-scale agile transition projects and his numerous speaking engagements around the globe have made him a true expert in the agile world.
Noel: With the current interest in lean strategies, how do you see lean’s effect on existing agile practices?
Ade : Personally, I've found that it tends to vary depending on teams’ existing level of agile maturity.
For example, when working with mature agile teams (some of whom might already be incorporating lean principles into their working practices without realizing it) I've found that once the team starts to consciously focus on becoming more lean, they tend to become more systematic and strategic about reducing waste and streamlining their processes. At which point you might see developers producing only enough code to satisfy the immediate requirement, less task switching, improved throughput, and a switch from a productivity to an efficiency focus.
On the other hand, teams who are new to agile and have no prior experience with 'lean' can often struggle to embrace lean strategies when exposed to them.
Noel: If a company is looking to implement or transition to lean and agile for the first time, is there an advantage to starting one before the other, or can they be successfully begun at the same time?
Ade : Great question - and one I'm sure you'll get different answers to depending on whom you're asking.
And since one size doesn't always fit all, I personally believe that the best place to start might be to look at a company's business objectives, constraints, culture, political environment, etc. first, and then chose the approach best suited to these - which could be agile, lean or a combination of both.
Noel: For those already using agile, who may not even know where they could use further improvement, where might they look first?
Ade : For someone who might not know where they could use or make further improvements, a good place to start might be with the question "If I could improve one thing, then what would that one thing be?"
For example, if a team decided they want to improve their product, they could start by getting it into the customers/users hands as soon as possible so that can get valuable feedback early. They could even consider shortening each iteration cycle so they can get that feedback even earlier.
Or if that team wanted to improve their efficiency, then they could look at how many features they were delivering per cycle that delighted the customer/end user; to improve time to market they could look at how to reduce the time it takes to release a new feature/product; to improve flow they might look at how they can reduce waiting time, remove non-value adding processes, etc.
So where someone might look first would depend on their desired outcome.
Noel: Do you see the core principles of the Agile Manifesto as something that will always remain concrete, or is it conceivable that years down the road, amendments or ratifications could actually be merited, due to changes in the way software is developed?
Ade : Looking at agile as an interaction model that goes beyond software development (we're already seeing agile being successfully applied in the areas of product development, social engagement, education, politics and at the enterprise level), I definitely think it's conceivable that the agile manifesto may change.
Especially since one of its core values is "responding to change".
Noel: Of all of the duties of a ScrumMaster, are there any that seem to commonly be difficult to stick to? It seems like it would be easy to begin to focus on one or two areas, and accidentally let something else not get the focus it also needs.
Ade : When first starting out as a ScrumMaster, a common area of difficulty I initially struggled with related to the role of the Servant Leader - specifically, how to maintain the balance between being both a servant and a leader. Lean too much to being a servant and it can make it difficult to maintain the team respect required to successfully fulfill the role of mentor and coach. Lean to much towards being a leader and you can unknowingly cross that invisible thin-line between leader and manager, which can easily lead to a 'command-and-control' situation.
Another common area of difficultly relates to finding the balance between guiding the team through the agile process and allowing them to try new things and learn from their mistakes.
But that's one of the things I enjoy about being a ScrumMaster - it provides you with ample opportunities to learn and develop interpersonal skills that transcend software or product development.
