I believe in the engineering team using Cobol and Fortran ’77 (so much better than ’66) to develop the best modern websites. I believe in them using note cards and excel files and Jira and Trello to organize the Agile Product Backlog, and using nothing at all. I believe in the teams having a leader and having no leader. I believe in what the team wants to do.
While a bit tongue-in-cheek, I truly believe that a successful, innovative, and evolving organization must encourage its members to decide how they get the job done. Trust the team to find what works best to achieve their goals, which of course should be aligned with the company goals. The effective leader provides vision, values, and transparency. The leader must protect the team by setting up the metaphorical guardrails by the cliff’s edge, but between those guardrails create an open and fertile environment for the teams, who are professionals and most likely smarter than the leader (that’s why you hired them!), to do what they do best.
If you want to achieve the best, get out of their way and trust!
That said, how do we prevent the organization from falling into chaos where one team is using Clojure, another Haskel, another Go, another Agile, another Waterfall, ad-infinitum? If we allow that sort of chaos to ensue, the engineering team will have serious issues with business continuity (shoot, Bob the Cobol guy just left – who here knows Cobol, anyone, anyone, Bueller?), hiring, and maintainability. The other extreme, which large organizations often adopt, is a regimented approval process for all technology, down to the version level. Do you want to use Scala 2.11.7? Well, write up a report, submit to the engineering committee, POC, review, and 6 months later and dozens hours of your time, maybe get Scala on the restricted list. Maybe.
But there is a better way to do it and that is Managed Chaos.* Chaos can be detrimental, but if properly managed, it can be a powerful tool for an engineering organization to embrace innovation and drive the business forward through technology. When the engineering team comes to you asking to use Cobol, say, “Yes! I support you. But, I do have some questions. Where do you plan on finding Cobol engineers? What about mainframes? I don’t have any here. Also, can you build websites in Cobol? Didn’t know that. How will you leverage other teams to get the help you need since no one here knows Cobol?” If the team has justification and has reasoned out how this will drive the product and team, allow the chaos to happen. You have managed the chaos by asking the right questions, thinking things through, and aligning to the business and product. You have embraced change that can drive the business and product forward by giving your team control (e.g. the tech stack).
Create a great engineering environment by giving your team control.
What you really are trying to avoid is the “Oh, yeah, we should have thought of that” statement after the fact. For example, if our Data Science team wants to start using MongoDB and our Platform team wants to use Cassandra, that is totally fine if they have thought it through and discussed why each team needs to use a different no-sql databases. That is Managed Chaos. We don’t want to have the discussion 6-months after implementation and say, “I guess there is no reason we couldn’t have used the same.” That is just chaos.
Another example is from a recent decision by one of our Agile teams at TheLadders. Most teams are either singularly use either Jira or Trello. However, one team for our Professional website decided they want the Product Owner to create user stories in Jira and the Engineering Tasks be broken down and estimated in Trello. I was dubious – really, both? Isn’t that, well, chaotic? It isn’t. The team had thought though the complexity and determined it worked for both the product owner and engineers, and I’m happy to say they were right.
In conclusion, don’t be afraid of change, don’t be afraid of the decisions your team makes, and don’t be afraid of managed chaos.
* Managed Chaos is similar in concept to Fractal Organizations. Below is a great description from Pravir Malik on how a Fractal Organization works:
“In meta-theory all instances of organization, from the smallest, such as an idea or a person, to the largest, such as global markets and planet earth herself, are fractals: the essence of their way of being is repeated on scales both smaller and larger than themselves. There is however, a particular class of fractals, that of progress, of which The Fractal Ladder is an ever-present manifestation, which spawns organizations that are truly progressive and sustainable in nature. In the scheme of things this class of fractals is of critical importance, and to master its replication and to fully understand the impact it will have in creating sustainable and dynamic organizations is a practical necessity.”
I recently presented at the Rally Agile Executive Talk Radio program on how best to approach the Daily Scrum (or Daily Standup for those non-Scrum folks). It was a quick talk – about ten minutes – and I thought it would be interesting to share the presentation.
Enjoy and let me know what you think!
There doesn’t seem to be many Twitter Lists of the top iOS developers out there – you would think Googling would bring up dozens of results, but it doesn’t! So here is a great start to a Twitter List of the top iOS mobile developers to follow. Click here to follow the list.
If it ain’t broke, don’t fix it – the common reasoning for not upgrading software, hardware, cars, toaster ovens, etc. Basically, new doesn’t always equal better. I can’t agree more, but when my mother-in-law gave me the same reasoning for not updating her iPhone apps, it occurred to me…she actually might be breaking her beloved apps by not updating them.
I spend my days developing iPhone and iPad apps, so I know the challenge to test older versions against the growing number of devices and iOS versions. If my app is at version 5 (having gone through version 1-4), I can honestly say I don’t really test versions 1-2 and maybe not even version 3 for backwards compatibility. Why would an old version break just because a new version is released? Well, it has to do with the back-end systems that are supporting the app. For example, all your friend’s Facebook wall posts appearing in your Facebook iPhone app come from the Facebook servers. This data is formated in a certain way and overtime as new features are added and others removed, the format of the data needs to change. Eventually, the older app (unless a lot of time and energy is spent) won’t understand the new data format and will stop functioning. So, while my mother-in-law thinks by not updating she is removing the potential for her apps breaking and saving herself hassle, she in fact is increasing and, for certain apps, inevitability breaking them. The moral of the story: Update your apps if you want them to keep working.
Great new article describing how to align Agile across an organization using Lean, Scrum and Extreme Programming (XP).
Check out this new article of managing distributed Agile teams.
Overview: A primary tenet of the Agile process is the co-location of the team. Ideally, developers sit only a few feet away from the Product Owner or business partners. This co-location typically facilitates several benefits of Agile: frequent communication and feedback, a sense of ownership, and team building. However, managers are often forced, due to budget constraints and corporate policy, to manage a distributed team comprised of both onshore and offshore resources. These distributed Agile teams often have unique challenges that the Agile process doesn’t address. This article discusses how to effectively manage distributed Agile teams by facilitating communication.
New Agile article detailing a “Day in the Life” from the perspective of an Agile Developer.
Overview: People are creatures of habit, particularly programmers: we seek consistency, whether it is the tried and true Waterfall/SDLC method or our morning routine of reading the newspaper with a hot cup of coffee. Companies or projects looking to adopt an Agile process usually begin by asking, “What is the ROI (return on investment)?” and “Will projects be delivered better, faster and cheaper?” While these are excellent management focused questions, they neglect the fundamental concern of an individual developer: “What will my day-to-day look like working in an Agile environment?” This article looks at what a “Day In The Life” is like for a typical Agile developer.