Been close to half a year since I took on this new job. They have a Purple theme and somehow it reminded me of Seth’s PURPLE COW book which was one fascinating read years ago. This is a different Purple altogther. 😛
Some of you have asked what exactly it is that I do. In a simple term, I deliver values to business. How?
Well, in my previous company that was done through a project implementation management role. Overseeing the implementation activities in rolling out an enterprise-level application that’s replacing an ageing legacy system across their offices which are located in over 18 countries. Forming, blending and leading a project team that consists of members from 6 diverse nationalities; each with a different stake in the ground.
When you are involved in projects of such scale, the tipping point is usually not project management excellence but making sure you get the change management part of the project done well.
Another area I can deliver value to a business is through organization development (OD) and operational management. Pretty much general management stuff but instead of the more mundane administrative aspect of general management, I love to dive into the challenging aspect of building high performance teams and the subsequent OD work that follows.
The challenge with this Purple Co. is stated in simple terms (though they are not easy to reach): Craft a culture for the KL office that supports an AGILE continuous delivery framework driven by self-organized high performing teams.
AGILE Software Development
The AGILE Manifesto was published more than 10 years ago. It’s now almost trendy for most software shops to say they are using the AGILE method. I’ve to admit I was a skeptic initially – probably after having grown up with the SDLC – and the early experiences I’ve had with AGILE was not favorable.
Projects over-ran. Teams never grasping the requirements (since there’s no formal requirement specifications drawn up before AGILE development commences). Customer not comfortable given they did not know when they’ll get what, and at exactly what price. In short, complete project disaster.
Took me some time before I finally understood the key drivers – and thus the critical success factors – behind truly successful AGILE teams. What are these?
1. You need to deliver something that works and has business value at the end of each iteration. Iteration is essentially a short development window of one to four weeks. Most teams run on 2-weeks iteration. That’s not a lot of development mandays in it.
2. Therefore in order to deliver working software with the right business value in that short period of time, the team has to focus on the really important stuff and ignore everything that’s not.
3. To achieve a successful iteration outcome, the team has to constantly look for feedback on the work they are doing, be prepared to change the game plan when necessary and above all else, be totally accountable for the outcome!
This is when I realized not everyone will fit this working culture nor likes to work this way!
The Agile Samurai book couldn’t have worded this more succintly….
“Delivering something of value every week (or iteration) is not for the faint of heart. It puts the spotlight on you like never before. There is no place to hide. Either you produce something of value or you don’t. But if you like the visibility, have a passion for quality, and have a fierce desire to execute, working on an agile team can be personally very rewarding and a heck of a lot of fun.”
In that sense, when a successful AGILE shop is saying they value people talent, they are not paying lip service and hymming the “We value our employees” mantra just to toe the latest human capital trend.
Avoidance of Responsibility
Many years ago when I attended the Money & You bootcamp, one of the key principles they extolled is “Take Responsibility; do not Make Excuses, Blame or Externalize the Issue.”
This saying couldn’t be more relevant to an AGILE team.
How many times have you worked in teams or departments and when things go wrong, you hear things like “Oh this one not our responsibility la. So-n-so dept should take this up” (blame) or “But you didn’t tell me I need to do this” (make excuse) or “This issue is beyond us. When a new policy like this is put in place, we cannot predict it” (externalizing the issue).
In AGILE, teams own the outcome. Not the activities or tasks. They either achieve the outcome or they don’t. If there are other external factors, excuses or blame that can put the outcome at risk, it’s the team’s responsibility to flag those risks early, mitigate them and be prepared for contingency. And not shift the accountability of not delivering the outcome to those external factors.
The RIGHT Context (and not Control)
You need the right type of people – and the right blend of culture – to make this work. That’s the most common root cause when AGILE projects failed. Companies either lack the right culture (ever worked in a “blame and political” culture?) or they lack the right people (sadly, most people tend to exhibit an Avoidance mindset… preferring to be safe rather than stepping out).
I’ve interviewed scores of people for software development roles (in this context, I’m not referring just to sw developers/programmers but to roles like QA, Biz Analyst, UX, etc) and the first setback is that more than 70% are actually in it becoz it’s a “job”. As opposed to being passionate about the practice of software development itself.
Challenge them with simple questions like “Given you are a dotnet developer, what would be the five things from Java (or insert your own language here) that you would like to see added to the ASP.Net framework?” and you get a blank face staring back at you as though you’ve just spoken Latin with them. 😛
When someone is in a role because it’s a job that gets them a paycheck, you see a “follower” and hardly any passion. These ppl will not evolve into thought leaders with their own opinions, be it right or wrong. It’s always safer to follow.. than to put forth your opinion and be proven “wrong” or worse, look like a fool.
There are 9 core values we seek in our people that help us shape the behaviors we want to see in our AGILE teams. Curiosity and Courage are two of them. And someone who follows a job becoz it’s a paycheck will always lack these two.
On the other hand, we don’t just hire for technical ability. Knowledge & Skills only make up two of the three points of the Competence triangle. The last one – and arguably the most critical – is Attitude. How many Brilliant Jerks have you encountered in your workplace? And how many fragile/emo but otherwise technically competent employees you’ve met where you always have to tiptoe around egg shells so as not to harm their otherwise fragile ego or self-esteem?
Self-Organizing for Success
One role that’s distinctly missing from an AGILE team is the Project Manager. There’s simply none. Coz we do not need someone to fill a position just so that he can map out a 6- or 12-months long plan, complete with WBS and spends most of his working time administering this plan. And then spend the rest of his time adjusting and fine-tuning that plan.
In AGILE, we have teams that owned the Release outcome, understood what values to deliver to the Business and as a team collectively organize their iteration backlog to deliver on the Release objectives.
Roles (Dev/QA/BA) are blurred, development activities (Analysis/Design/Programming/Testing) are done continously and interchangeable by team members, and team accountability (vs silos) are what will crush an AGILE project.
Note: The verb “crush” is used in the context of “completed or finished, usually in an entirely satisfactory manner” and not in the negative context of failure. This “crush” context is also seen in Gary Vaynerchuk’s book Crush It!
A Deep Purple Journey
It’s early days in the transformational roadmap and there’s still much to be done. Q3 should see us getting closer to the Continuous Delivery Framework which is a key differentiator to software companies in this internet and cloud era. Those days of waiting months for a market release is long gone.
With key partnership with ThoughtWorks, the leading practitioner of Continuous Delivery, the transition plan can only look exciting in the coming months!
After having been with TPM for a good many years, we’ve finally decided to move to Bangsar South. I only joined this Purple Co. in Feb this year so I can’t say I miss TPM. But I certainly will tell you Bangsar South is the right move and THE place to be!
Obviously the opportunity to re-design the new office allows us to put in the FUN aspect of being in an AGILE team! A pool table and a WII console are among the additions. The Pool table is always a busy spot during lunch-time, break hours and after work. Surprisingly the WII gets lesser play-time. I’m not complaining coz as a boardgame afficiando, I’m biased towards electronic gaming.
Has boardgames made an appearance in this Purple Co? Not yet.. but it’ll. Inevitably soon. 🙂
We also believe FUN has to be part of a team’s DNA. We actively encourage team to make it FUN to work here…. NEFR guns anyone? 😛
Finally, I’ll be so looking forward to the day when UOA can get this 6-acre park (which is just next to my office block) ready… looks like a good place to do my evening runs after-work? 😛
To follow more of my thoughts and writing on Agile, Lean and work; do check out my other blog www.aucheekeong.com
Till next, be Purple!