I believe that early, effective big picture diagrams are key to application development project success. According to the old saw, no project succeeds without a catchy acronym. Maybe so, but I’d say no project succeeds without a good big picture diagram. The question: what constitutes a good one? To me good high-level diagrams have four key characteristics: they are simple, precise, expressive, and correct.
How does this sound as advice for an app dev manager leading his or her team from waterfall to Agile?
- Clearly articulate a compelling end-state vision
- Work from a position of authority
- Weather the storms
- Reward creativity while fostering improvement
A post at scrumsource.com lists leadership, organizational culture, and people as three of the five key factors in making the transition. Another at the Scrum Alliance site describes the transition as a migration from externally-organized to self-organizing teams. In my experience the transition requires leadership by a strong advocate who shows the way to willing, empowered team members.
The US men’s national soccer team (USMNT) is playing out a strikingly similar transition. Continue reading
I recently stumbled upon one of The Martin Agency’s hilarious Geico caveman ads and wondered, rather geekily, why they didn’t do one about data analysis. I think if a caveman suddenly arrived in the 2010s he or she would see parallels between his life and the activities of today’s knowledge worker. When I thought it through, it seemed obvious that knowledge workers need to be more like farmers and less like hunter/gatherers if they want to achieve the full potential of business intelligence.
This is the latest entry in an occasional series on followership. The premise, as stated here, is that not everyone gets to be a leader, and most leaders are also followers in their own right. The project manager follows instructions from the project sponsor, the CEO from the board, the politicians from the polls, and so on. Whoever you are, you spend a lot more time following than leading. As Bob Dylan put it so well, “you gotta serve somebody.”
The good follower is not a “yes man“. In the professional world I inhabit those who move “up” the hierarchy tend to retire technical skills in favor of architecture, proposal writing, and management. The relationship of manager to employee becomes more like agent to actor or musician, where the supervised employee is the “talent”.
In these conditions the old concept of top-down decision making seems quaint. Important choices require information from all perspectives, and organizations shut out those with knowledge of the details at their peril. The best decision makers search out diverse ideas before choosing a direction. Continue reading
Recently the BBC posted this video. On first view it is just funny, but watching those dogs learn to drive really reminded me of personal experiences with IT teams making big learning transitions. To represent those real situations let’s consider a fictional team of SQL developers facing the daunting task of deploying a functional Hadoop-based analytics prototype in two months. The video parallels their critical learning success factors: (1) set audacious goals, (2) learn bit by bit, and (3) know your limits.
“A child of five could understand this. Send someone to fetch a child of five!”
– Groucho Marx
Recently my colleague Sara Shelton posted an article listing non-technical things we IT specialists need to do to maintain our careers. Each of the nine items on Sara’s list is a key to IT professional success. One particularly worthy of a drill down was learning:
“It is critical for the technical professional to hold themselves accountable…to learn new languages, new tools, emerging technical trends, and best practices. With technologies changing more than ever, technical professionals need to focus on their own learning to stay on par with or ahead of the curve.” Continue reading
OK, I’ve lost a five-metre scrum, my pack has been overrun, and the ref has raised his arm between the sticks for a penalty try. My colleague Margy Thomas, with support of fellow rugger Billy Tilson, has convincingly argued that agile development in fact is very like rugby union. Margy cleverly fended my meager one-point case with a point-by-point list of the ways that agile projects and rugby are similar. I’ll hold on to my view that sports analogies are generally weak in describing application development, but I’ve come to observe a fundamental similarity between rugby and agile/scrum. Continue reading
What if you could double the efficiency of your software testing process, and substantially reduce errors found during the test, deployment, and maintenance phases, without purchasing any tool or method? The November 28 InformationWeek offers just that in a reprint of a recent Dr. Dobbs article on formal inspections by Capers Jones and Olivier Bonsignour. They call formal inspections the “defect removal tool of choice” and back up their claim with lots of hard evidence, but I think they are still selling short. Continue reading
I’ve never understood the obsession with “green” status among IT application development project managers, and the intense pressure put on them to “stay green” by the program management offices (PMOs) they report to. We would benefit from a cultural shift away from avoiding yellow status.
For those not in the field, it is in vogue to express IT project status using a stoplight analogy, where green means things are going well, yellow indicates some quality, schedule, or budget risk, and red means there’s imminent risk of failure.
I recently completed ScrumMaster training ably presented by Lyssa Adkins. Throughout the two-day class we appreciated Lyssa’s Zen-like, enabling, style. If her name is familiar, it’s because Ms. Adkins is the author of the book Coaching Agile Teams, one of the leading texts on the subject.
I’ve participated on agile projects, but so far only in a piggish/chickenish role, once in a three-week stint as a consulting architect and twice as the project manager serving as interface to the non-agile organization.
To me Ms. Adkins rocks at making students very introspective and critical of their past project experiences. These lessons stand out: