Pragmatic Agilist

What can we all do, in the IT industry, to ensure that women enter the field and rise to the highest level within it?  So far, most advice has been directed to women themselves, in the form of "here is what you do." Sheryl Sandberg recommends " leaning in ," advice which was already obsolete in 2011, when Catalyst's 20-year longitudinal study showed that "leaning in" doesn't work for most women, because many female leaners-in get accused of being pushy people who can't play well with others. My ThoughtWorks colleague Magdalena Frankiewicz  has recommended a great book on this topic, Williams and Dempsey's What Works for Women at Work .  This book is very pragmatic, and I like it a lot.  You must read it!  I discouraged, however, that one of today's key approaches to getting ahead involves the individual woman fine-tuning her gender presentation, becoming more assertive if she is super soft-spoken ( Nice Girls Don't Get the

The title of Martin Fowler's classic 2003 "bliki" post, " CannotMeasureProductivity ," almost says it all.  Why "almost?"  Because, by the end of the entry and to complete the thought, Fowler concludes that we also should not even attempt it: I can see why measuring productivity is so seductive. If we could do it we could assess software much more easily and objectively than we can now. But false measures only make things worse. ( CMP , final paragraph) Ten years later, Fowler tweets that this sentiment is "still true and still needs to be said," although he qualifies this statement to clarify that " You just have to go with whatever subjective assessment appeals to you. Just remember that it is subjective. " Productivity measures are depicted here as some kind of mystical siren, luring unwary executives onto the rocks of wanting to get best value for their investment dollar. Ulysses and the Sirens by J. W. Waterhouse

There's a lot out there about how to use MS-PowerPoint, starting with Edward Tufte's advice to NEVER NEVER use it .  An example from Edward Tufte of what you should do graphically, instead of using PowerPoint.  http://www.edwardtufte.com/tufte/minard But I cannot resist this chance to throw my hat into the ring.  What if you are not a graphic designer, and someone asks you to build a PowerPoint deck, and the thing they need to know about is not Napoleon's invasion of Russia? I am a person who prefers to put as little effort into this as possible, so you will not get any cool design tips from me.  But to me, a very pragmatic and plodding user of the PowerPoint technology, the handiest thing is just to have a good example to follow, and guess at the rest.  So you can skip the rest of the blog and just look at this handy sample if you like!  That's what I would do. If for some reason you are still reading, then in my opinion, the following are the most importan

Do you have a group of, say, 100 people, whom you want to organize optimally for a software delivery program?  Martin Fowler is famously on record saying that " scaling agile is the last thing you should do. " A better approach is to try to scale down your project. ...an unscientific straw poll revealed that most projects could lose about half the people of the project without making things go slower. Time and time again I hear of success occurring when a team is cut significantly in size. Large teams carry a big overhead in communication and management. Using smaller teams staffed with more able people is usually faster and cheaper, even if the everyone is more individually expensive. This brings to mind one of Tom Waite's "non-lethal weapons," the Shrink Ray, in the movie Mystery Men ,.  Aficionados of the movie (or comic) will remember that the ray is "based on simple dry-cleaning technology." From the Blu-ray site:  http://www.blu-ray.com/m

Mike Cottmeyer has re-emerged in the blogosphere, after a bit of a lull, with an electrifying series of posts about enterprise agile, one of which is entitled How to Structure Your Agile Enterprise .  I love the whole series, and especially this post, anchored as it is in Cottmeyer's real life experience: First of all… let me share that I have NEVER worked on a small agile team. I’ve coached many of them, but my introduction to agile was in the context of large enterprise class financial systems… things like online banking and bill payment. The kinds of systems where the company makes a penny or two on every transaction and does millions every year. Is this your enterprise business flow reality??  From http://thedailywtf.com/Articles/The_Customer-Friendly_System.aspx Cottmeyer provides some really crucial insights about agile at scale that may run counter to what you believe is "fundamental" to agile: "Feature teams" are not practical, if any given

As agilists, we all hear a lot about self-organizing teams.  I'm pretty sure I have already aired several, probably conflicting, opinions about self-organizing teams, like " someone else should assign people to the teams and decide what they should do, and THEN they should self-organize ," but today I would like to talk about something even more fundamental:  the self-organizing self.  Are you fully able to function on your own behalf, or even on the team's behalf, at times when you don't have a scrum master acting as a sort of personal time assistant?  Do you procrastinate?  Are you distracted?  Do you run out of money?  Do you lose things?  Let's assume you've tackled work--how well-armed are you for life? Helpful advice from  http://xkcd.com/337/ I would like to think that most of you are more personally organized than I am, and you probably are, but for those of you who need a little help, as I do, there are some free or cheap techniques and onl