Showing posts with label Productivity. Show all posts
Showing posts with label Productivity. Show all posts

Friday, July 13, 2018

Introducing: "SWARMing"


Hello all! I popped into Dan North's blog to see what he's been writing about lately. Dan North introduced BDD (Behavior-Driven Development) to the world which bridged a huge gap between the Customer and the Team.




His latest post "In Praise Of SWARMing" grabbed my attention. I thought it was going to be about "swarming" a problem as in Kanban. But it's actually a different-ish approach to adopting Agile at Scale. SWARMing is Scaling Without A Religious Methodology.






His ideas really hit home with some great points! There are some harsh criticisms of competing methodologies. Those are somewhat tasteful. And I have to warn you, its a bit wordy. At over 4200 words, it's quite a bit more than your average "browsing the internet" post.


Here are some things that really jumped out at me.

The Good Parts



I particularly like the contrast between "moving the work to the people" and "moving the people to the work." This translates to reorganizing. The term "self-organizing teams" comes to mind.


I do prefer the flat structure of "every part of the org is geared in delivering value" vs the slanted structure of "sales makes the money and everyone else spends it." It allows businesses to utilize all their assets in focus of value delivery.




I read once that value is expressed as the benefit for the cost. A "good value" doesn't necessarily mean inexpensive. It means you actually got a return on your investment, monetary or otherwise. I wonder if looking at your organization from a "good value" perspective would make a positive difference.


Speaking if value: There are a couple terms worth following up on. OKRs are a relatively new way to set and measure goals. I learned about Risk-Adjusted Return on Investment, which is your profit plus or minus risk.


The Bad Parts

The post is long. It has quite a few run-on sentences. The upshot is that it's not an easy read. My concerns are that you (dear reader) won't see through to the beneficial parts. Please press on, it's worth it!


You've also got to see past the sales-y aspects. He's pretty tough on competing methods of implementing Agile at scale. He's right with those points, but it drags the article and makes for a slightly bitter taste. Sorry.


I get it, he's selling consulting services and differentiating from his competitors. But that wouldn't really be necessary if the most valuable points were laid out without the cruft. Maybe do those parts in a future post dedicated to a comparison.


The last "bad part" is the focus on hard numbers. These days, organizational psychology says to keep your focus on doing good for your customers. But that depends on perspective I suppose. Those with the pocketbook will care about the revenue aspect, especially when they're being told to rethink how they allocate funds!

The Rest




Somewhere past halfway, Dan iterates over eight points about how to be SWARMing. Some of those go into depth with definitions of types of leaders: servant-leader and leader-leader. This section has some practical advice for hiring services to help with your transformation process. The successful transformation will be a long and investment-intensive road, so buckle up!

Conclusion

I sent Dan an email asking if he had a more concise description of SWARMing. One that, hopefully, lays it out without the heavy padding. Those things are valuable to support the idea, no doubt! But I can't exactly expect busy execs to read such a lengthy argument all at once. Especially when it's a new idea which asks them to rethink their organization from top-to-bottom, front-to-back, and side-to-side.


All in all, I'd say it's worth taking the time to read his post. With the right packaging SWARMing could be a catalyst for much needed change. I hope it gets that with a bow on top.





Monday, October 9, 2017

Cause of Death: Optimization

So you've got this team - developers, business reps, product managers, QA engineers and they all need to work toward building out products that add value to the business (either directly, by reducing risk, or increasing efficiency). The business has some goals. You have some goals. Bonuses and career advancement and frankly job security are tied to those goals.

At the same time its difficult to find the right people. There are plenty of applicants but who can be trusted and who has the right level of expertise to jump right in and get things done because the backlog is growing and the work is piling up and everyone wants to know if you can deliver and of course when.

The New York Times wrote up a great article on how to find the right candidate. The thing is, once you've found the right candidate (well-qualified, energetic, enthusiastic, etc..) what happens next depends. Lets walk through the process and see why.

Ramping up


In order to make good on your deliverables, you need more headcount so you can get more done. You're at capacity and just can't ask your people to put in anymore. Once that's approved you now have the task of staffing the right person. You need to throw someone in straight away and start knocking things out because your way behind already and in order to justify the added cost, you want to show results.

So now you ask around internally - this is the standard pattern - if anyone knows someone who is ninjas at xyz. I'll tell you right now everyone who is ninjas is currently working. You'll need to do some sales - or typically hire a salesperson (recruiter).

So now you're in it with the recruiters for about 20% give or take. For a 100k salary, that's 20k...say I bet that 20k would make a great training budget! The person you really think you need actually costs more than $100k. First off in a supply and demand economy where supply is limited and demand is high you're on the downside of that. So $130 plus all the other costs and recruiter fees.

After the Onboarding

Once you've shelled out the upfront costs and now this maverick is on your team they'll need to be brought up to speed. For a while this will slow down overall production. One or more of your resources will need to be involved regularly in working with the newbie to get them up on the tools, practices, procedures.

It'll take some time before the dust settles. Lets estimate 4-6 months depending on the learning curve for a well-designed, documented, unit tested, and maintained system...1-2 years for most systems...longer for train wrecks. You are likely to be in the 1-2 year range and please don't lie to yourself because that's counterproductive and were focusing on being more productive. If you know I'm wrong in your case, then you probably don't need me to tell you all of this anyways, you can close the tab and carry on as you were.

Once the Dust Settles


If you're still with me and haven't gone back to balancing your budget or sipping your morning coffee while touring your friends' feeds, I'm glad you decided to stay because it's about to get real.

Taken on the surface and without considering long-term stability, hiring the right person in that moment is a greedy optimization. Greedy optimizations seek to optimize the whole by optimizing the parts of the whole with the hopes and assumptions...well...that it will improve overall performance. Often active stock traders attempt to do the same. Rarely does it work out; one reason is that active traders are likely to sell when things go south. In stock trading, emotions sabotage long-term results. In the same way, needs-of-the-moment hiring practices sabotages long-term health of the team when not considered along with overall team dynamics, culture, and performance implications.

A rockstar-unicorn-ninja-whatever is not going to solve your productivity issues if those issues arise from broader optimization issues - morale, communications and team cohesion especially. What WILL happen if there are deeper rooted issues is that the ninja will come on for a bit, do some things and ninja-smoke off when they figure out how deeply rooted the issues are which causes a degradation of the three most important factors to said ninja - autonomy, mastery and purpose. Not only do we strive for those three, but we are inherently social beings - nature calls for having social well-being. When our social well-being is not upheld we will fall behind our potential.

And you're still on the downside of the market, so there's that problem. I will guarantee you that salespeople are at it regularly pitching the great folks on your team. Any give one of them has inboxes full of emails and messages from recruiters. The other side of most of those openings are mirror images of yours in that their either adding or replacing staff because they've got a pile of work to get done yesterday. Some aren't but most are.

Solutions

You've got to offer something they don't. Compensation, bonuses, and benefits are a given in any decent market. Anyone worthwhile can get those anywhere. Your business may operate in non-IT markets and perhaps are on the upside of the supply chain (unlike in IT). But in your technology departments you're on the demand side - you need good people and the supply is limited.

In order to combat such a position and come out ahead you have to optimize for the long-haul. There may be some short-term goals that occupy much space in the present, but even if those are met you may end up in a position that doesn't set you up well for the next steps, the next goals...it's all about being strategic! Look for more global optimizations rather than local ones - unless the local optimizations truly do lead to a global optimum.

What you've got to do if focus on 2 things - optimizing your workflow and retaining talent. Both of those involve investing in the talent you've got on-hand. If you are willing to take a $20k hit for hiring new personnel or a $120k+ hit annually you certainly have the ability to work on improving the personnel you already have. Additionally, you can certainly afford to improve your system or process. Take a serious look at any bottlenecks - technical or otherwise - and address knowledge gaps, personnel conflicts and process issues BEFORE adding more calamity to the mix by hiring.

Get out there and spread some buzz in the developer community about your organization. When you're ready to hire - when your house is in order and you are prepared to properly on-board - you'll have developers coming to you rather than having to hard-sell. Basically you'd be marketing which makes it easier to sell. Having a great team, process, and organization to brag about is a great way to attract the top talent that you will now be able to retain.

Non-Solutions


Consider hiring all rockstar devs. They may all be fantastic in their own right. And at the same time if they can't work well together or communicate or the process hinders productivity anyways or they end up building the wrong things - it doesn't matter how good each one is.

And how about the case of pushing to get a release done? By pushing I mean everyone working late and just churning away...dropping principles and mounting up debt to get the thing done. That's a way to burn folks out and in this heyday of IT, that's a recipe for exodus. As far as turnover goes, going back to the active traders, fees are costly and chew away at the gains. You've got to have retention for the long-haul.

But that's not the only danger with churn and burn. What's left behind may end up slowing things down significantly in the future. Move too fast, slap things together, drop important practices and time for reflection, team building, etc and it'll only lead to further entrenchment of negative reinforcement - a negative feedback cycle. This has been well-known for a long time now.

Adding people will always slow things down for awhile. Adding them to a late project is classic mistake that no-one should be making anymore.

Outcomes of Successful Solutions

Once you've applied a successful solution, you should be able to compare the outcome to the baseline. That's right, make sure to capture your current state so that you can KNOW that you've solved solved the problem.

You should be seeing better employee retention, improvement of skills, lower stress, higher morale, engagement, proactive behavior, lower bug count if you'd like to address that metric, and more valuable production if your process is really in order. The latter may be beyond your own sphere of control, but perhaps it is not beyond your sphere of influence, but since this post is about the productivity of your own group it may well be beyond scope for now. However, that's arguable since your productivity should actually be measured by the actual value delivered. I'm sure to do a post in the future about that.