- the First Law of Consulting--there always is a problem
- the Second Law of Consulting--"no matter how it looks at first, it's always a people problem"
- the Third Law of Consulting--if you solve the problem too fast, it's going to be embarrassing
- the Fourth Law of Consulting--"if they didn't hire you, don't fix their problem"
- the Orange Juice test--"we can do it, and here is how much it will cost"
- Brown's Brilliant Bequest--listen to the music and the words
- the Buffalo Bridle--you can make 'em go anywhere, as long as they want to be there
- the Credit Rule--don't worry about who gets the credit
- the Duncan Hines Difference--it tastes better if you add your own egg
- the First Law of Trust--"no one but you cares about the reason you let them down"
- the Fourth Law of Trust--"the trick of earning trust is to avoid all tricks"
- the Five Minute Rule--"clients reveal the answer to their own problem in the first five minutes"
- the Ten Percent Solution Law--"if you happen to achieve more than ten percent improvement, make sure it isn't noticed"
Thursday, December 24, 2009
Sunday, December 13, 2009
Thursday, December 10, 2009
Thursday, November 26, 2009
In The Reflective Practitioner, Schön follows the working habits of architects and engineers. In that book, we see people making predictions as to what their situation will support; then they do some of their work and watch what the situation actually produces, and from that, they alter their understanding. They update their understanding of the problem and the proposed solution according to the changed situation and their new learning. This “reflective conversation with the situation” is just what the Wright brothers did in designing their airfoil.
Craft implies skill in working in a medium, mental or physical. There are many materials in an engineering project and therefore many skills or crafts to become adept at. Some people need people management skills, others need mathematical skills, others need visual design skills, and so on.
Each skill and material brings its own specialized vocabulary. Ceramicists “wedge” clay and study the shrink rate of different glazes compared to clays. Civil engineers work with the tensile strength, fatigue rates, and thermal expansion of their materials. Writers look for flow and development in their texts. Programmers look at cohesion and coupling, testability, clarity of expression, and computational complexity in their algorithms. Testers work with test coverage and probabilities of occurrences. User interface (UI) designers work with cognitive-motor task switching times, recognition times, color scales, and user work patterns. Project managers work with people and are concerned with what builds or tears down trust, community, and initiative.
In each case, craft practice requires practitioners to have a reflective conversation with the material, using the specialized vocabulary. They work with the constraints offered by the materials, the vocabulary, and the project.It is this deliberate, reflective, intentional improvement that we're trying to support with the Agile Skills Project. Do you have something you'd like to contribute? What can we create together? Sign up for the Agile Developer Skills (http://groups.google.com/group/agile-developer-skills) group, and let's talk!
Tuesday, November 17, 2009
In Philadelphia, our team focused our code by naming projects, classes, and methods in ways that business stakeholders would recognize. This made it so we shared a ubiquitous language, as Evans calls it, a clear set of names that make sense to both developers and stakeholders. Something we didn't do enough of, though, is refactoring as the terminology evolved. We did practice merciless refactoring, but it was driven primarily by technical needs. Evans also mentions that the natural language of domain experts will be imprecise and self-contradictory, so it's important to be able to create, together, a new language that is unambiguous. Humans are especially adept at creating language, and the process of using our new shared vocabulary will propel us to simplification--we naturally find easier ways to say things. By implementing these verbal shortcuts in the code, it is simplified as well. The resulting deep model will constantly evolve as our understanding of the domain improves, and our communication about the domain will become more and more precise. In fact, the communication can become so precise that Evans reports an end of the "mystifyingly unexpected requirement changes". The new language used to describe the domain model can be so powerful that it's a selling point for marketing purposes, it's a market differentiator!
The following are points I underlined in the book, but may not make much sense to anyone else:
When we're working on a domain model, name things to reflect intention, rather than implementation. Evans also likes "closure of operations" because they perform operations that bring along no other dependencies (closure means input/output are of the same type).
Evans presents many ways to simplify the domain model, for example:
- by constraining many-to-many associations with a clarifying attribute
- minimizing the number of associations
- making associations uni-directional
He also discusses entity objects, value objects, and services, the last should optimally be an operation that does not fit in either an entity or object, it takes some entity or object as a parameter, and it's stateless.
The Repository pattern is a way to keep caching/data store and retrieval from polluting the domain model. Essentially, the repository objects will act as if they are a permanent in-memory collection of persist-able objects, with even some helper methods for quick retrieval of often-run queries. Repositories are made to retrieve existing objects, while factories create new.
Monday, November 9, 2009
So tonight we held the first meeting of what I’m calling Agile Besançon… it builds upon some organizing work that Ludovic, Olivier, and Regis have done in the past—going back as far as the coding parties that Olivier held at his house. Tonight’s meeting was held in a conference room at Temis Innovation, the incubator for the startup I work for, Smartesting.
Ludovic and I facilitated a discussion on Managing Multiple Projects at Once. Conventional Agile wisdom recommends against multi-tasking, and against running multiple projects with the same team, because task-switching incurs a heavy performance cost. Still, some teams cannot get their management or their customers to focus—so how can they cope?
We started the meeting with a brief check-in, describing how we hope to have monthly meetings where we can play, practice, and discuss topics/skills that we don’t normally address during our work day. Then we showed how we planned to use the time for the evening—check-in until 7:15pm, game until 8:15pm, and retrospective until 8:30. We all introduced ourselves with name, job title, and company affiliation, 11 in total, 3 companies represented.
Ludovic and I had invented a group exercise to help people warm up to the ideas we’d be presenting—the object of the game was to use an assembly-line of workers to build paper airplanes—15 copies each of 2 different models. We started with a 5-minute prototype phase—and the Acceptance Test for completion was that the plane had to be able to fly across the room. After a brief pause, we gave each team (of 4) 5 minutes to build their planes—but they were forced into a Taylorist production model—one person rips out a page from an old magazine, next person puts one fold into the sheet, next two people are plane builders—of the kind of plane they had prototyped. In 5 minutes each team had built about 6 planes—and we then talked for 5 or 10 minutes about what we noticed. Then each team had a 5-minute huddle on how to improve the assembly line, followed by another 5 minutes of production. This time each team produced 16 planes—but one team focused on model A, while the other team built both types. Only one team noticed a hidden requirement written on the whiteboard—that the customers only pay for completed batches of 15 planes. Afterwards, we talked about the strategies the teams used to speed up (moving more people to the plane-building role, thanks to Theory of Constraints), and we talked about what might help them reach the goal of selling both plane types. Someone suggested re-negotiating the batch size requirement—and we said that is an excellent way to deal with multiple projects—that as soon as we can get to small releases (minimally marketable features), it’s not as penalizing to switch off to another project—but to switch before releasing means shelving the unfinished investment and therefore indicates waste. We followed this discussion with a perfection game on the game itself:
The notes, translated from French, indicate that we should keep the:
- short iterations
- brief reflection after each iteration
- simple materials
- prototype phase
For next time we might consider changing:
- construction targets—different objects, like a boat and plane, or simple folds instead of more precise objects
- don’t run an acceptance test for everything?
- the number of projects (have more than 2), and find a way to get people more actively involved in decision-making/collaborating
- making different objects worth different prices, maybe depending on the construction cost
Points of confusion, open questions:
- what was the overall goal?
- how can we help people be more collaboratively involved?
- deliver airplanes?
We ended the night with a quick Blond-ROTI chart (Return-On-Investment):
Translated, on a scale of 1-10, people rated the following:
- Worth it to come to the meeting tonight: 8
- I learned something: 5-8
- I will change something tomorrow: 1-7
- I’m ready to lead a discussion for the next Agile Besak: 2s and 8s
- I’ve encountered this problem: 1s and 9s
- Would it be interesting to have more of us: 8-10
- I will invite someone the next time: 9-10
- I’m ready to come the next time: 10
- There should have been more experience reports [tonight]: 10
Thursday, October 15, 2009
So, with the caveat that the group may quickly change direction (we're all agile, right?), I'm happy to report on where I think we're going. We'll be creating the Agile Skills Project, an ongoing, open, and not-for-profit entity that will do the following. But first--who is the "we" that follows? Assuming that you're at an experienced practitioner level, it probably includes you:
- create an "agile skills inventory"--a list of skills that are important to being a good agile team member (note, this is not just for coders), a definition of those skills, and even links to existing learning materials (books, web sites, courses, classes) that may help one acquire these skills. These skills will be mapped to the Seven Pillars, and specific ones will be selected as fundamentals that every well-rounded agilist should know
- provide a way for individuals/teams/orgs to self assess against the inventory--this can be an index into where they should focus self improvement efforts, or what kind of help to seek, paid or unpaid.
- recognize progression along the agile skills inventory--the intent here is to celebrate the successes we make in our life-long learning; the risk would be that people could misconstrue this as an endorsement of a particular competency, which it is not. We see several levels of progression through a skill: exposure/awareness, attempted, successful execution, refined execution, advanced the state-of-the-art. From the "successful execution" level and up, there would be third party verification that the skill was indeed performed correctly.
- characterize learning materials--we'll be able to map existing courses, certifications, conference sessions, books, etc. back to how much they cover the agile skills inventory. This will give a nice "nutritional content" to these learning materials, and help people see the objective value these materials provide
- collect experience narratives--at some point, all this work should tie back to the correlation between delivery and skills. This will provide data that correlates successes and failures to how we do the work.
- review experience narratives--With experience narratives, we'll be learning from practitioners in the field, and be able to improve the Agile Sklls Inventory accordingly. As a nice byproduct of experience narratives, we'll have a paper trail of what progress individuals have made in their learning journey.
Wednesday, October 14, 2009
-defining an Agile Skills Inventory (e.g., Active Listening, Story Splitting, Test-driven development)
- providing a repository for reference courses
- defining self/peer assessments
- defining a quest ecosystem
- experience reports
- characterization of external courses (for a fee?)
- rating of trainers for a particular course
Well, this is what we're trying to imagine, and here's how we attacked it today--in several sessions. The group asked me to help facilitate (thanks, Pat, it was a great honor! though I'm not sure if I did in fact keep us on task):
We pondered what value this system would produce, so we talked a bit about supply and demand:
Then we talked about the idea of "a quest ecosystem", or points, or merit badges, or achievements, and ultimately thought it could be called tokens. Basically, we'd like to acknowledge the work people do to improve their developer skills:
Then we tried to clarify what this Agile Skills Project would be all about:
Essentially, what we see right now is that the community would own and maintain the ever-evolving definition of agility, then certify training organizations/courses/study material against the standard. To help developers, these 'certifications' would characterize the courses; alternative free methods would also get characterized as well--so then it's up to the developer to take a course or teach oneself.
To further help the community, we'd have a 'token' system, by which team members could go on learning 'quests' or exercises, which would be recorded in a web site as an experience report. This report would be rated by peers and generate points for both the reviewer and reporter. These points would not be fungible, would have no external worth, but could be used to help people categorize their own strengths and weaknesses, to prioritize further learning quests.
One of our group members took some of the initial 7 pillars work (technical excellence, collaboration, product understanding, supportive culture, business value, confidence, continuous self improvement) and made a wordle picture:
Tuesday, October 13, 2009
We soon moved into a mindmap of our various motivations:
Then we brainstormed on a list of personas that may be our "customers" or stakeholders.
The next steps are to filter the list of proposed outcomes and to review, in detail, potential "generally accepted curricula" that could be used in various courses.
In the wake of announcements from the Scrum Alliance and Microsoft on a "Certified Scrum Developer" program, that would cost around $4-5k per developer, Ron Jeffries and Chet Hendrickson are hosting a discussion on how we, as a community, can support skills development for developers/agile team members. In preparation, I hosted an open space discussion on the topic at Agile Tour Besançon, and a parallel session ran in Agile Tour Philadelphia. The community has long resisted any developer certifications, for many reasons:
- existing schemes don't seem to measure the most important skills
- certificate possession doesn't seem to correlate with skill
- certification has been expensive
When I spoke with other developers, the following topics came up:
- how is any test/class going to show if I'm good at my job?
- who is going to pay for the test/class?
- why should the Scrum Alliance or Microsoft or WAQB or any company be able to define agility?
- what happens if people get the cert and I don't?
I also had a nice conversation with Laurent Bossavit about the topic. He suggested that at the workshop we ban the word certification--that way we'd have to reveal the motivations for wanting the program at all. He feels like certifications are a replacement for a system of trust--but once money gets thrown in, we need a way to justify the system--a way to explain what people are paying for. One motivation for creating a system would be to show who in the community is worthy of emulation... to show what behaviors are valuable, what practices are effective. In any case, this system should be community owned, democratic, and should value/reward life-long learning, while still fostering innovation towards better ways of developing software.
Wednesday, September 30, 2009
Tuesday, September 22, 2009
Focus on the user and all else will follow.
Lean demands that we identify what our customer needs, then we deliver just that. She talks about how the Quicken team entered a mature market of complex accounting software, simplified it, and delivered value to their customers. She mentions Google, Dell, Zara--all companies that have risen to success because they have the right focus.
Why isn't it waste to design things we won't use? It's because waste has to be regarded in context of the whole system--and failing to deliver an acceptable design is a much bigger waste than optimizing the whole.
Wednesday, September 2, 2009
Tuesday, September 1, 2009
- Partially Done Work (it delays feedback, thus increasing the risk we didn't catch mistakes; our investment cannot turn a profit if it's undone; we risk falling out-of-synch with other people that continue to work on the previous version)
- Extra Features (this is overproduction and the worst form of waste because it's at the top of the food chain, i.e., it inevitably included all the other forms of waste somewhere in the process of creating the feature)
- Relearning (if we already paid for one developer to discover something, why pay another developer to do the same thing? still, it's very difficult to have a usable system of documentation that explains why we chose what, when)
- Handoffs (tacit knowledge--that which can't easily be explained verbally or on paper--forces the recipient of a handoff to re-do part of what we've done)
- Task Switching (task switching increases the time-to-completion of the most important task on our plate, or causes waste in terms of unfinished work or relearning)
- Delays (when developers have to wait for a customer's opinion, they may guess or pause. Either way, it's waste.)
- Defects (in my opinion, defects may be on par or worse than Extra Features as waste... we've gone through all the work of making a feature, and then have to revisit it, re-test, and re-deploy.)
Thursday, August 27, 2009
- Toyota's productivity is "consistently four times that of its competitors, and quality is twelve times better", says Jeff Sutherland in the forward.
- The book begins with a 2-page history of the industrial revolution. Starting with the late 18th century French invention to use standard, interchangeable parts for firearms, the US ran with the idea to create mass manufacturing and economies of scale that had never been precedented. Then in the early 20th century Taylor applied the idea to people--making the work of automobile assembly line workers so easy they could be trained in 10 minutes, and therefore be easily replaced. This was in strong divergence with what happened in the loom industry in Japan, where the automated looms required a lot of expertise to maintain and tune--here, individual skill was highly valued and teams were preserved, even as companies were torn down and restarted.
- Just after WWII, the Toyoda family (future creators of Toyota) felt the need to catch up with American mass manufacturing, but they did not have access to the wealth of resources required to benefit from economies of scale. Instead, they aimed for "just-in-time flow", which gave them the advantage of driving down the cost of variety in their products. The Poppendiecks say that this is "the only industrial model we have that effectively manages complexity".
- Jidoka -- autonomation -- "Toyoda automated looms... detected when anything went wrong and shut down automatically". This sets the stage for a "stop the line" mentality, mindfulness, safety and quality.
- When there are mistakes, it's not the worker's fault--it's the process which has room for error. Fix the process so we can't make mistakes.
- Plant managers were all expected to spend some time on the line.
- It is the creativity and practical knowledge of the line workers themselves that drives continuous process improvement
- Lean is infectious--Toyota and Dell have extensive supplier networks, and freely exchange information and training to support the supply chain. They define contracts in a way that align the interests of both companies.
- Peter Drucker states that "a company that maintains a single management system throughout the entire value stream will see a 25 to 30 percent cost advantage over competitors"
- BAA built terminal 5 at Heathrow airport with a novel kind of contract, including target cost and a risk/incentive pool. Whenever a subcontract finished, contractors got paid the target cost plus anything that was left over in the incentive pool. This aligned the interests of both parties, and work went more smoothly.
- the Toyota Product Development System is designed for "generating and preserving knowledge for future use"
- in product development, it is not waste to explore multiple options/technologies--they call this "set-based concurrent engineering"--these options allow us to evaluate trade-offs appropriately when the time comes to make a decision
- "repeatable and reliable speed is impossible without superb quality"
- the Kano model states that to impress customers, we need to satisfy basic needs, as well solve problems they weren't even aware of
- "behind every great product there is a person with great empathy for the customer, insight into what is possible, and the ability to see what is essential and what is incidental"--Martin Cagan of the Silicon Valley Product Group
- chief engineers at Toyota play a product owner role--they are responsible for the business success of their vehicle family, and they do first-hand research (genchi-genbutsu "go, see and confirm") of their potential customers as well as pay attention to marketing research and dealers
- inspection to prevent defects is necessary; checking to catch defects is waste
- just-in-time decision making is critical to effective risk management. The longer we wait to commit to a particular path, the more we know about our options--but if we wait too long, some options vanish. Establish, up-front, when key decisions need to be made, and then adhere strictly to those timeboxes. See set-based design.
- "above all, team members must be mutually committed to achieving a common purpose"
- "unused features are the worst kind of waste in software development". Justify every feature!
- "great software grows out of a mind-meld between a person who really understands the business and a person who really understands the technology"
- simplify--both the product and its implementation
- part of the design must incorporate the concerns of operations staff--people that will support and maintain the application
- seek a "product" funding model, rather than a "project". Products are funded incrementally, evaluated on their return on investment, and are released incrementally. Like landscaping or gardening, custom projects are never done. When a "product" is championed by business leaders, it is more likely to have business value.
- Don't automate a complex process. Simplify the process, then code it.
- When a lot of work needs to happen quickly, we need "self-dispatching" work--that is, remaining work items need to be evident to everyone on the team, and people need to see the overall status of the group
- a discussion often changes once a "decider" has been selected. Make it clear who that decider will be, and then watch the arguments unfold.
- it's important that proposed changes in a system are done scientifically--so we can evaluate the old against the new (PDCA)
A value stream represents the work we do starting with a customer order and ending with delivery of that value. The map needs to be detailed enough to uncover problems, but should also abstract sufficiently so we can see the big picture
- long delays indicate queues--we want to get rid of queues because they represent an unfulfilled need, a warehouse of undelivered value that wastes money to sustain, and they inhibit feedback from the customer
- process loop-backs indicate churn--if you're re-prioritizing, re-checking, re-designing, re-doing, it's waste!
- balance the workload
- minimize the items in process
- minimize the size of work items
- release regularly
- limit work to capacity
- use pull scheduling
- Lean can only be realized when there is true respect for people in the workplace. At Boeing in 1988, the 777 project started with the premise of "working together"--and this fundamental respect for people ended up creating a work environment that shares many attributes with Toyota's lean process.
- Deming wrote about how to use people's full potential in the workplace: "appreciation for a system (synergy of parts), knowledge about variation (problems come from the system itself), theory of knowledge (Plan Do Check Act), psychology (skill, pride, expertise, confidence, cooperation)".
- Also see Deming's 14 points to increase quality.
- Deming said that a company's purpose is to create products that please the customer so much that they'll keep buying more products--that is, to make a sustainable system, focused on long-term relationships
- In a lean organization, problems aren't recurrent--they aren't systematic--because as soon as a problem is detected as systematic, the system is changed
- "standards are viewed as the current best way to do a job, so they are always followed"--anyone who finds a better way is expected to change the standard documentation
Friday, August 14, 2009
One means of networking I hadn't heard of before I came to France was first introduced to me by my colleague, Olivier--"tourisme industriel", or industrial tourism, a year ago, as a way to accelerate learning and improve the team's experience. Just this past week we had two "tourists" come in to observe our dev team--and while they didn't have a lot of experience with Agility, it was refreshing to have a new pair of eyes on our process--their questions came much more freely than an intern's or a new team member's, I believe, since they weren't expected to integrate these practices--they were simply here to find out if it made sense for them. I'd be really interested in trying this back in the States on a long-term basis, but the companies I'm familiar with would likely be too concerned about intellectual property to try it. Because of the questions from the tourists, we took a few minutes yesterday to do a special retrospective on whether we should change anything in our process. The tourists noticed that our connection with the XP client was excellent, that our adhesion to the Pomodoro breaks was lacking, and that the idea of deploying to prod was valuable.... Well, no changes came out of this retrospective--we're going to just keep going with our half-hearted Pomodoros, because we think it makes sense in our particular situation ;)
Wednesday, August 5, 2009
- In every coaching opportunity, find ways to deliver value to the recipient--otherwise, your changes will not stick around for long. As a coach, I'm constantly asking people around me to leave their comfort zone, to do things I believe are possible, but they don't. But if I can find their currency, this change will be something they value.
- Each individual has different motivators, of course! Each person has different ways they like to be acknowledged. Tailor your interactions!
- Timing is everything--we're shooting for specific goals and we need to reinforce good behaviors; the amount of effort or time we put in to this isn't important, it's the results!
- The coach needs to stay focused until the recipient has made the new practice a habit, and will create opportunities to practice if necessary!
- The coach needs to provide clear expectations.
- We don't care about volume, breadth, utilization, effort, or percent done. We are focussed on a narrowly defined objective.
- A coach encourages learning by asking questions more often than lecturing. Often the difficulty is in applying what we've learned to our daily habits. Ask the team/individuals about what's going on, or how principles might apply to specific behavior.
Tuesday, August 4, 2009
- Procrastination, forgetfulness, and being overwhelmed in our lives can be replaced by energized work
- Our brains have a lot of natural rhythms and tendencies. There's a reason why sports stars have quirky game-day habits. Let's capitalize on our brain's natural strengths!
- Follow a ritual for winding up the Pomodoro... it frees your mind for more important things. Capitalize on building good habits!
- Our brains are not good at task switching, because we have limited "working memory"
- Our brains are very good at finding associations. Many memory techniques teach us how to build those associations.
- There are two ways to understand time: sequential vs duration. Sequential is more intuitive for children, and is less anxiety-prone for us adults
- To get into flow, it's helpful to have the right environment: clear goals, sufficient challenge/interest, alertness, immediate feedback, and the sense of control.
- Analysis paralysis is a symptom of having too many choices. If we limit our task selection to the beginning of each pomodoro, we don't lose time constantly rehashing what to do next.
- The difference between a to-do item on an Activity Inventory and what's on the Today list is commitment. Maybe other people assign items for our to-do list, but when we do Pomodoro, it's our choice to schedule things for Today, and it's our goal to get those items done...and our satisfaction to succeed. It's critical that the commitment is realistic!
- Each Pomodoro day has the following stages: planning, tracking (something, each pomodoro), recording (consolidate to Records Sheet), processing (analyze the data), visualizing (retrospective).
- The key to memory is rehearsal. If you want to remember something, review it now, a day later, a week later, a month later, and then again 3 months later. This will strengthen the neural pathways so the info is easy to reach. As part of Staffan's daily retrospective, he draws a mind map of what he learned during his primary task of the day.
- There's something about commitment that adds fire to our work. Use this catalyst by planning the day with a Today list, and use a Now List at the beginning of each Pomodoro to keep focused.
- The daily retrospective is important to keep us learning.
- Interruptions occur. Negotiate to keep them from interrupting your flow. If it's really urgent, you'll have to void your pomodoro. If you do anything that is not on to your "Now List", the Pomodoro is void (unless it didn't interrupt your flow and it took less than 10 seconds).
- External Interruption Negotiation--inform the other party you're in the middle of a pomodoro, and will be done in X minutes; ask if you can get back to them then; add it to your Today list or Activity Inventory
- Tracking: Staffan records interruptions (' for internal, - for external), unplanned items (U), estimation error (boxes for initial estimate, circles for re-estimates, and triangles for 2nd re-estimates)
- At a minimum, each break begins with getting away from the active task--i.e., standing up from my desk!
- Giving ourselves regular breaks brings multiple benefits: ability to reprioritizate tasks, tendency to view the larger context and discover new associations, and clear delineation between work and rest.
- Flow is incompatible with a perspective of the big picture. So we need something to wake us up, regularly, to ensure we're still on the right track.
- Much of the discipline in Pomodoro is about setting up artificial rewards... I get a 5-min break if I work for 25, I get an X on my sheet if I don't get distracted, etc.
- Short breaks give our brains a pause from a bombardment of stimulus. Get away from machines and texts! Otherwise you're likely to develop "attention deficit trait"--i.e., you're stealing focus away from the next pomodoro.
- Breaks are critical to get us out of flow-mind, and allow us to switch to overview mind--where we're capable of making changes to priority/schedule/plans. It may be hard to be disciplined to stop when the bell goes off, but if instead we realize this is a wake-up call, it's no longer something being imposed upon us... it's our choice to be able to reevaluate where we should be going
Friday, July 17, 2009
We use "one pomodoro to rule them all", which means one timer for the whole team. I've read this is an anti-pattern, but I don't see a compelling reason to use more than one pomodoro. We see a lot of advantages in having one pomodoro... everyone has a pause at the same time, so pair swapping is easier, team meetings are easier, etc. If someone's pomodoro is interrupted, someone decides not to participate in this pomodoro ("check-out"), they just wait until the next pomodoro starts to rejoin the synchronized timer. As a team, it seems like we're happy to use Pomodoros--our team communication is up, our productivity, our focus, our check-in/out is all better.
Our biggest problem with Pomodoro right now is in sticking to the 25 minute window--when the timer rings, inevitably someone stops, but most of the team keeps working for another 2 or 4 or 5 minutes. When the 5-minute pause is over, 3 or 4 people approach the story board and start goading others into joining them. This can easily make a 5 minute pause take 10 minutes, at which point we have a mini-standup meeting to verify that we're not blocked or overbudget on any story cards, that we're progressing well, and to verify no one needs extra help.
We've talked, as a team, about why people aren't taking breaks, why people are late to show up after the break, etc. Maybe this pain is why it's considered bad form to use "one pomodoro to rule them all". If we keep just one timer, though, what else could we do to fix our tardiness?
Monday, July 13, 2009
Thursday, July 9, 2009
Thanks to George Dinwiddie for the pointer to this image (actually, I don't know the etiquette here in terms of referencing an image from another site...), but anyway, this model can help a team gell. Read more at George's blog.
Note the change in focus here--I'm talking about getting a job done. There's no intrinsic value in the software itself--but there is potential to accomplish a task, and therein lies its value. Yet it's rare that my needs correspond exactly with the software's behavior. So if it doesn't do exactly what I need, and there's a free one that is just about as inadequate, why not go for the free option?
I'm not alone. The prevalence of free web software (from list serves to social networking to banking), plus the thousands of open and closed source software products that are available free download, suggest that there may not be much time left for people that are still trying to sell their software.
Now for the irony--I've been paid for years as a 'software developer' for in-house applications, and there are lots of other workers getting paid to contribute to free software. Where's the money coming from? Where's the value? As I've already said, it's not the software. The value comes from getting the job done better. The less software involved, the better (per James Shore's spag code debt model). I think, then, my job isn't to write software. My job is to solve business problems... to figure out what the business really needs, to deliver value, with as little technology/effort as possible.
Wednesday, July 1, 2009
Growth through creativity --> leadership crisis (small team, informal leadership)
Growth trhough direction --> autonomy crisis (single level of management)
Growth through delegation --> control crisis (middle managers)
Growth through coordination --> red tape crisis (executive managers)
Growth through collaboration --> growth crisis (matrix organizations, partnerships with internal groups)
Growth through alliances
Tuesday, June 30, 2009
In business, power comes from these five forces.
Supplier power: more suppliers, less power for each one
Threat of new entry: if it's a profitable business, someone is likely to jump in to compete
Buyer power: big buyers can dictate terms (think Wallmart forcing Coke to give them a discount 10% lower than any other buyer, or Amazon taking 70% of newspaper revenues)
Threat of substitution: if there's another way to meet the customer need, maybe the customer will use that solution instead
Competitive rivalry: competitors tend to drive down the price to the "marginal cost of production"
PD: hierarchal vs cooperative leadership/power
IDV: individual vs community
MAS: clear, different gender roles vs gender equality
UAI: avoid uncertainty, like formal structure vs informal and tolerant of risk
LTO: long-term orientation, value family and education vs valuing shorter feedback and innovation
Monday, June 29, 2009
Sensory <--> Intuitive
Visual <--> Verbal
Active <--> Reflective
Sequential <--> Global
These learning styles show a preference for:
Sequential: details or steps used to build the big picture
Global: use the big picture to figure out where the steps should fit
Friday, June 19, 2009
- everyone takes care of themselves
- everyone fully connects with each other
- everyone unanimously agrees on one objective and how to achieve it... this unanimous agreement should be so strong that every member of the team believes that this objective is the best real option, right now for reaching both our individual and group goals
- everyone expects that perfecting the team will perfect the product
Thursday, June 18, 2009
- their basic needs (keep the work environment sane, fair, with competitive benefits)
- their motivational needs (job satisfaction comes from challenge, recognition, autonomy, interesting work, and room for growth)
Monday, June 15, 2009
Thanks to my colleague from Philly, Nolan, for coining this phrase!
- describe the need/ultimate goal
- encourage sign-up for responsibility
- define authority depending on skills, how critical success is, and whether there's room to clean up any mistakes--should this person act independently, review plans with you, or review intermediate outputs before proceeding?
- once you've given out authority, you must hold back, even if mistakes are about to be made... being given the room to make mistakes is how we learn
Friday, June 12, 2009
- setting the stage (why are we here, time line, and check-in)
- data collection (put all the facts in front of the whole team)
- interpretation (as a group, look for patterns)
- decisions (propose options, then decide on what can be done by whom, when, and define acceptance criteria for the work)
- closure (ensure tasks have been assigned, thank participants)
- ask the group to build working agreements, and then just remind them to follow their own rules when necessary
- at every meeting, get every person to speak in the first 5 minutes
- check your assumptions... ask people what they think! pose clarifying questions to make sure you understand!
- to help everyone have a voice, incorporate small group work in the meeting
- retrospectives are for creative thinking--so do use innovative meeting formats
- when the facilitator speaks, this often stops group discussion
- when the group is stuck, ask them questions, e.g. about when they saw a similar problem in the past
- when things get heated, try asking "what is going on?/what just happened?"
- use a change in venue when the team bombs an iteration
- most people can't absorb multi-step instructions
- debrief every activity
- after giving instructions, ask for questions
- shuffle time--it takes a few minutes every time we switch tasks in a meeting to get everyone on board with the next meeting--it could be 15 percent of the time!
Tuesday, June 9, 2009
Hey, Joe, wanna take a tour de témis? Joe may not be available, but if so, we step out of the team room and find somewhere quiet--outside or inside depending on the weather and mood. Then I'll ask one of the following questions, and record responses on an index card:
What are the strong points/weak points in the team?
What do you think about how we've been using timeboxing for meetings this week?
What will you do next week to help us finish the iteration by Thursday afternoon (instead of our normal Friday)? Do you think it's a good idea to finish early?
Then I use Appreciative Inquiry to dig deeper into what is going on with each team member.
Fixed-scope: We understand the end-user's need, and we'll spend however much time it takes to meet that need. In this case, we value a well thought-out solution over feedback--so we should choose this only when end-user needs are well understood. The end-result of this process is a story card that is done-done, and the subject will likely not be revisited.
Fixed-cost: We understand the end-user's need, but the schedule is more important than functionality. We'll cut out features, robustness, or complexity so that we can deliver something that at least partially satisfies the end-user's need. As a by-product of this process, we'll write new story cards for everything that we temporarily cast aside. In this case, we value timely feedback from the timebox over completeness--so we should choose this option when we're unsure of the best solution or when doing research.
The first thing I tried was to use retrospectives to find real pain points in the team... but not everyone agreed on what the highest priority items were. Then I tried using positive reinforcement of goals that I'd chosen. I wish I could say we chose these goals but there was no common consensus, so these goals were usually the collaborative output of Olivier and I, or the output of several team members... but for simplicity's sake I'm saying that I worked for the following. Please note that most of these changes were introduced to the team one at a time, and allowed to become habitual before moving on to the next item:
- more pair-swapping
- shorter story cards
- avoidance of black holes
- lighter-weight story card estimation
- emphasis on TDD rather than Test-After
- up-front face-to-face discussion with the client for every story card
- introduction of fixed-cost story cards
- focus on fewer changes so we can do those few well
- Agile Thought of the Day
None of this really created a gelled team, in fact much of it was probably just a distraction from our real problem (at least from my current perspective). It probably wasn't a waste, since these changes have become a valued part of our daily work, and have also helped to establish a level of trust in the work I'm doing. Still, this more effective group work didn't translate into a performing team. Why?
I felt like if I could get everyone to see and focus on one single problem simultaneously, that would become the shared vision that defines a performing team. I concluded that I needed to construct an unambiguous definition of success... which, again, I pushed for. I believe it would have been more effective to have the team define this success, but I couldn't get the group to agree on one goal. So, I said that an iteration was not a success if we hadn't moved all the story cards over to the DONE column by the end of the iteration. I shared this vision consistently and regularly at stand-ups, my turn as story-observer, at retrospectives, and with my pair. Slowly the team adopted this vision... slowly means it took 10 weeks! Since then, however, there's been clear consensus on whether an iteration is done or not... yet that didn't make a gelled, performing team! Now what?
I needed more information, more ideas. So I started doing one-on-one interviews with every person (12 total) in the team, every week. That's been effective at understanding how people feel, and in making other types of changes (like finishing our iteration before 8pm Friday nights... now we're done Thursday afternoon or Friday morning). So with these interviews, I discovered I wasn't alone in feeling like we weren't a gelled team... people wanted closer cooperation, stronger teamwork, but we just didn't know how to get there.
As I said before, XP Day France was a great opportunity for me. I now know we need to get through forming, and I figured that if I shorten the cadence, we'd learn quicker, we'd have more pressure, and communicate more... all setting up fertile ground for team forming and agile growth. So I suggested we try the Pomodoro technique (as a team) last Thursday. Afterwards, we decided that the practice was too complicated to evaluate in just one day, and Olivier decided we should try it for an iteration. Well, that iteration began this Monday, and few people actually read the free 40-page book (hooray--some people are giving it an honest shot), but for the rest I've been using the first long pause of the day to explain the practice in more detail.
Everyone uses the same, 25 minute timebox. After each pomodoro, we pause, then have a mini-standup, where the sole objective is to find out how the team is going to attack the remaining story cards. If someone is blocked, we might send help to that pair; if someone has something interesting to share, they do; otherwise, we may resume the task we were on before. The object is to efficiently select the most important tasks that remain.
The breaks are ad-hoc, and may involve a team-building game, drawing on the white board, or a walk outside. This has become self-organizing already--different people propose games or set up the timers. Just to note, we play games that stimulate the creative, left-brain, so that when people go to sit back down they're more likely to see creative alternatives in the new pomodoro.
On a larger scale, the objective is to add so much discipline that we start to storm.
I'm hoping that before this month is over, our team will just be able to sense when a pair goes dark, will know when to swap pairs, will know how to focus on the core need inside a story, and will hum like a hive, producing a continuous flow of honey (err, business value).
Friday, June 5, 2009
Then he starts talking about some of their training, training I know I don't have. Interaction Designers learn about common reasoning flaws, like (the following is paraphrased from Cooper's slides 82 and 83):
- Loss Aversion
- Value Attribution (initial perception counts more than contradictory evidence later)
- Commitment Bias
- Pygmalion Effect (self-fulfilling prophecies)
- Tyranny of small decisions (too much choice is paralyzing)
- Evolutionary Psychology (we're not machines, and don't always act logically)
- Abilene Syndrome (groups make choices that no one in the group even wanted)
- Memory Distortion (bad things are easier to recall)
- Hawthorn effect (just paying attention to people improves their performance)
- Stockholm syndrome (hostages fall in love with captors)
Interaction designers are designed to distill "requirements" into a clear definition of business need. I can identify with this idea, as I've heard of teams that thrash from one set of whimsical story cards to the next. When I worked in Philly, we had a product owner who was also visionary, who strongly defended the vision against customer requests that were inconsistent with this vision. At my current position we've been saying that we need that vision to be more effective, but no one is playing the role.
Next he argues strongly for prototyping. He says a prototype is necessary for validating the design... and it should be built in a very agile, lean fashion. Then once it's done, rebuild the whole thing from the ground up... I thought that refactoring was supposed to avoid rebuilding to such a large extent. There's a lot to think about here.
Forming: agree on goals/vision as described by leader (team lead is directive at this stage). Members hold back their own opinions in order to be polite, they mostly work independently on tasks.
Storming: (directive leader) there's a lot of competition for ideas, the team begins to select a leadership model, and roles are clarified
Norming: (collaborative leader) members compensate for each other, agree on rules/standards, and hold each other accountable
Performing: (collaborative leader) interdependent individuals with established conflict resolution mechanisms.
A group in N or P will fall back to S under stress, in which case the team lead will need to be directive again.
So I think a team needs to be at either N or P to do agile. It's possible that at F or S the directive leader of the group will impose an agile process... but it won't be self-organizing!
Friday, May 29, 2009
velocity 1 2 3 4 5 6 7 8 9 10
confidence in product 1 2 3 4 5 6 7 8 9 10
team cohesion 1 2 3 4 5 6 7 8 9 10
People added a tick next to their rating, and then quickly added other topics. The white board became a hotly contested resource... people were scrambling for markers and/or room to write.
Tuesday, March 24, 2009
www.scouting.org/ ( http://www.boyscouttrail.com/game_search.asp and http://www.usscouts.org/usscouts/games/game_t.asp )
Then at XP Day Suisse I picked up a few more:
I'll be trying out some more games soon!
Friday, March 20, 2009
Agility depends so much on face-to-face communication, I think that our developers need higher emotional literacy skills than they've needed in the past. So when I've recruited developers in the past, I screen for emotional literacy. I don't know how to teach it... at least not teach it quickly. What do you do?
Wednesday, February 25, 2009
Monday, February 23, 2009
Then something magical happened. Thursday morning people started talking about their ideas, and their conquests, during slack time. Some people were working on clean-up, some were doing exploratory testing, and others were innovating the next great features for our product. I knew slack was important for maintaining quality and a sustainable pace, but I forgot about the innovation side. In Philly we started saying that innovation was still there--all you had to do was write up a card and get the customer to buy it. All we had to do was convince the customer? Well, that worked well enough for senior members of the team, but new members just didn't seem to have the sway to get their story cards picked. So they'd sneak off in the dark and do their prototypes or proof of concept, then show it to the customer. This got in the way of collective ownership and the spirit of a team of equals.
Last week, we had a new excitement brewing as the iteration was winding down. People were signing up to do interesting little projects, and getting excited about all the clean up they'll be able to do in slack. This will hopefully carry over to this new iteration and help people move the cards fast!
So anyway, having a significant buffer of slack (hey, why not 20-30%) is critical to the health, sustainability, and innovation in the team. Here's to finishing the iteration on Wednesday or Thursday!