Saying 'No' doesn't have to be mean nor painful
Via
The Shade Tree DeveloperTaken from
Andres Taylor's Top ten things ten years of professional software development has taught me:
When I started working, I was very eager to please. This meant that I had a hard time saying no to things people asked of me. I worked a lot of overtime, and still didn't finish everything that was asked of me. The result was disappointment from their side, and almost burning out on my part. If you never say no, your yes is worth very little. Commit to what you can handle, and if people keep asking you for more, make it very explicit that this would mean not doing something else. What I did was to have a list of stuff that I needed to do on a piece of paper with me. When someone asked for something, I showed them the list and asked what I should bump to have time to help them. This allowed me to say no in a nice way.
It's not easy saying 'No' and sticking to it. It can be
so painful that we sometimes avoid it just to avoid short-term pain, only to find later that the long-term pain is even worse. We can feel mean for saying 'No' and so we offer reasons that justify our decision and soothe our bad feelings. But each reason you offer may be countered by a reasonable argument for taking the opposite position. And eventually you might surrender and change your decision to 'Yes'. If you can't say 'No' and stick to it, your 'Yes' is meaningless and it's gonna hurt.
Try using
Satir's Soft Spurn to say 'No' without offering reasons and without feeling mean. First show appreciation, then give a regretful 'No' without any reasons, and make an opening for some future relationship. For example, "I'm flattered that you'd ask me. Unfortunately, I'm unable to do that at this time."
Tags:
communication
Links to this post
If everything is equally important, then nothing is important
Via
The Shade Tree DeveloperTaken from
Andres Taylor's Top ten things ten years of professional software development has taught me:
The business likes to say that all the features are as crucial. They are not. Push back and make them commit. It's easier if you don't force them to pick what to do and what not to do. Instead, let them choose what you should do this week. This will let you produce the stuff that brings value first. If all else goes haywire, at least you've done that.
Links to this post
Agile Alliance on Certification
Here is the
position statement on certification from the
Agile Alliance. I've highlighted what I believe to be the key points.
This position statement is released by Agile Alliance board in response to questions we receive from our members regarding certification in Agile.
Now that Agile software development is becoming a mainstream practice, more and more employers need to staff teams that will perform it well. How can they know if a particular person will be an asset?
One way might be to favor employees who are vouched for by some certification body. It is the position of the board of the Agile Alliance that employers should have confidence only in certifications that are skill-based and difficult to achieve. We also believe that employers should not require certification of employees.
Certifications in our industry usually tell you that a person has been exposed to particular knowledge. Some certifications additionally tell you that she has passed
a test on that knowledge.
Knowledge is a wonderful thing, but businesses pay for performance. Performance requires skill.
A skill is not as simple to acquire as knowledge: the learner has to perform the skill badly, recover from mistakes, do it a bit better, and keep repeating the whole process. Especially for the interrelated and interpersonal skills required of Agile software development, much of the learning has to take place on real projects. It is that learning that a certification should vouch for.
Vouching for someone else's skill requires close observation or questioning by someone already possessing it. For anything other than uninterestingly simple skills, that's a lot of work - which means it's expensive. Therefore, the only skills worth formally vouching for are those that require substantial effort to learn.
While a skill-based certification can shorten the hiring or promotion process, there are many skilled practitioners who are not certified. Excluding them from consideration would be a poor business decision.
Moreover, the state of the practice moves on.Skills decay when unused. The question is not whether an applicant once possessed appropriate skill; it's whether the applicant can do what's required today. A certificate cannot substitute for the hard work of individual evaluation.
Certifications such as Certified Scrum Master and DSDM Foundation are knowledge-based and easy to achieve. We believe the courses that lead to them are good ones. We believe people who attend them get their money's worth. But while the certifications may be evidence of good faith, useful knowledge, and a desire to learn, they are not in themselves evidence of skill.
Higher levels of certification, such as DSDM Practitioner or Certified Scrum Practitioner, require project experience, a written project synopsis, and an oral examination. They are skill-based. Other organizations like the Agile Project Leadership Network are working on skill-based certifications. We applaud their efforts.
Tags:
agile certification
Links to this post
It's a stragedy
A strategy is a plan of action to achieve an overall goal. But when a meeting convened to devise a new organisation structure produces the same kind of hierarchy, just dressed up a little differently, it's more like a tradegy than a strategy. It's a
stradegy, if you like.
Strategising about organisation without considering the affect of corporate culture probably isn't going to get you the improvements you want because
culture eats strategy for breakfast. When a company is pickled, it's not necessarily blind to its problems but it is often blind to the root causes of those problems. It's strategy for change is preoccupied with fixing symptoms.
Tags:
culture,
strategy
Links to this post
Ready-to-go agile team
If anyone needs a ready-to-go agile team, experienced in XP and Scrum and based in the UK,
get in touch. The team I've been working with over the past year will be available around the end of April and we're looking for a fresh challenge. This team is the best I've worked with to date. It's a
real team. It's cross-functional, self-organising, and innovative. The people are accomplished practitioners with values and principles. And we have a lot of fun together. It's a team that delivers.
Links to this post
Calling in well
Via
Peopleware
Chances are you've heard of people calling in sick. But have you ever thought of calling in well? You'd get the boss on the line and say, "Listen, I've been sick ever since I started working here, but today I'm well and I won't be in anymore."
Some organisations are so screwed-up that you'd have to be a bit crazy or 'sick' to keep going back.
The person who calls in well is ready for work that is fun, creative, challenging, energising, and enhances self-regard.
Links to this post
United Intent: Teams not groups
I've seen groups of people masquerading as teams. But I don't believe that they are teams. There isn't a team spirit. They're simply groups of people that have been asked, or more likely
told to work together on something.
You don't build teams. You grow them. And in the right environment their growth is a natural phenomenon. As a team grows, you start to see cohesion. The people in the team bond and jell and the whole becomes greater than the sum of the parts. In
self-organising teams it's understood that it's better to succeed together than to succeed because of some individuals and not others.
A team grows around a shared vision or goal accompanied by shared criteria that define success. (These should be set out in a
charter, constructed by and unanimously agreed to by the whole team, i.e. every single person in the team, at the very start of the project).
A vision that is shared unites the people in the team and focuses their intent. They pursue the attainment of their vision, together, with gusto. You see mutual support begin to develop and you see solidarity and collective ownership.
As people work together they tune into one another. As they make commitments to one another and hold one another accountable to their commitments, mutual trust develops and they begin to experience the camaraderie of being part of a team. The team begins to develop an identity. People in the team gain a sense of belonging, they feel part of something powerful and perhaps unique. They demonstrate loyalty to the team. People motivate themselves. They enjoy their work and they have fun. There's a healthy aura as interactions are confident and convivial. Friendships form and often extend to regular social activities beyond work. People work better and achieve results because they've got momentum.
Tom Demarco said:
A team can become an almost unstoppable juggernaut for success. Managing these juggernaut teams is a real pleasure. You spend most of your time just getting obstacles out of their way. Tags:
team
Links to this post
Developing business awareness and acumen
Marco Abis says:
The single most important benefit brought by the Agile movement to the industry is a sort of Business Awareness. I finally see and hear people, regardless of their official role, talking about business value and how they can help deliver it. I see technical people interested in return on investment, opportunity cost, GDP and sometimes cash flow.
Seeing everything in terms of its inherent business value is a good thing. And it would be better if that business value could be represented as a figure that contributes to the bottom line. Sometimes this is straight forward. Other times, it's not so easy. Everyone involved needs to understand the various monetary factors in a project and how they affect one another. Everyone needs to understand the financial consequences of decisions and actions, or lack thereof. It's not good enough to leave this to project managers or finance people anymore.
As
Marco goes on to say:
The next step is developing Business Acumen.
Tags:
business value
Links to this post
Multitasking is a way to avoid prioritisation
Jack Vinson on
the pernicious thinking behind multitasking:
Multitasking is an implicit means to avoid conflicts around setting priorities.
Johanna Rothman comments:
Management, especially senior management is unwilling to make the hard decisions about what's most important to do.
Links to this post
Pull the wool over your eyes
If you're still doing things
the old way,
Jason Yip provides some useful tips on
how to create the perception that everything is okay.
In
Peopleware
,
Tom Demarco referred to something similar as
management with hysterical optimism.
Don't skip the Prime Directive
If you think the
Prime Directive is silly or corny, or you sigh or snigger when it's read aloud at the start every
retrospective,
George Dinwiddie reminds us what it's all about and why it's so important:
As we look back on that unchangeable moment, we may still think, "I should have done such-and-such. I knew it at the time, but I didn't do it. I could have, and I should have." What good does this do us? It may make us feel bad about ourselves. Or, being the high-achievers that we are, it may steel our resolve to do better in the future. Either way, it doesn't equip us with the knowledge of how to do better in the future, because it doesn't uncover the reasons why we didn't do better in the past.
We may apply the same attitude toward someone else, "He should have done such such-and-such. He should have known it. He could have done better and he didn't." Now we've compounded the problems even more. By blaming the other person, we incite defensiveness on their part. Perhaps anger or shame, too. We pile unhelpful emotions onto the situation, burying the facts we need to see. And we poison our relationship with the other person, destroying trust in both directions.
Quoting Wallace C. Ellerbroek, George says:
"Bearing in mind that there are many factors of which I am unaware." What excellent advice that is! It's those very factors that we want to discover. As we examine that boneheaded move that our colleague made, we want to tread very lightly so that we remain respectful of the person.
Tags:
retrospective
Links to this post
The scene about agility in A Few Good Men
Comedy gold! I assume everyone has seen
A Few Good Men? Well, here's
A Few Good Managers (reproduced in full) from
Robert Holler:
Development: "You want answers?"
Marketing: "I think we are entitled to them!"
Development: "You want answers?!"
Marketing: "I want the truth!"
Development: "You can't handle the truth!!! Son, we live in a world that requires software. And that software must be built by people with elite skills. Who's going to build it? You, Mr. Marketing? You, Mr. Sales? You, Mr. Finance? You, Mr. Human Resources? I don't think so.
We have a greater responsibility than you can possibly fathom. You scoff at our open work areas and you curse our big screen monitors. You have that luxury. You have the luxury of not knowing what we know - that while the cost of delivering software may be excessive, it drives revenue and saves money. And my very existence, while grotesque and incomprehensible to you, drives BUSINESS!
You don't want to know the truth because deep down in places you don't talk about at staff meetings... you want me managing the project. You NEED me managing the project!
We use words like refactoring, test-driven development, continuous integration, sprint, velocity, and release planning. We use these words as the backbone of a life spent delivering something. You use them as a punch line!
I have neither the time nor inclination to explain myself to people who rise and sleep under the very blanket of software I provide and then question the manner in which I provide it. I would rather you just said "thank you" and went on your way. Otherwise I suggest you log in to a computer and write some code. Either way, I don't give a damn what you think you're entitled to!"
Marketing: "Did you cut the automated, edit sync [insert favorite feature here] feature?"
Development: "I did the job I was hired to do."
Marketing: "Did you cut the automated, edit sync feature?"
Development: "I delivered the release on time."
Marketing: "Did you cut the automated, edit sync feature?"
Development: "You're g%$#@*& right I did!"
Links to this post
Adapting Scrum without compromising it
Via
InfoQ,
Jason YipTobias Mayer recently described
some successful adaptations he's made to Scrum.
Jason Yip summarised:
- Don't separate the technical and non-technical members of the team.
- Shorten iterations (1 month is too long) and focus on end-to-end cycle time.
- Use smaller tasks instead of task estimation.
- Make tracking visible in the workspace.
- Quality engineering practices are not optional.
- Process leaders should make themselves unnecessary.
I totally agree that 1 month is too long for an iteration. When I first started doing Scrum, we used 30-day sprints and I quickly saw
student syndrome set in. We tried 2-week iterations and had some improvement but I still saw people take their foot off the gas in the first week and then struggle to make it up in the second week.
You can't beat
1-week iterations. They force everything to be smaller. Complexity is broken down by smaller
user stories and they can be estimated with less inaccuracy. A great visual indicator of progress is a steady rise in
running tested features as stories hit the
done column every day. Planning games are shorter because you do less in a week. And by the time you start you need to be thinking about finishing because iteration reviews come fast, so communication is more intense. You get to inspect and adapt every 7 days, and
celebrate success 4 times in a month as opposed to once. And this
builds momentum.
I don't like planning with tasks because, when user stories are small (typically 1 to 2 days of effort), tasks belong to the developer-pair. They form a 'private' to-do list that reflects how the developers will get the story done. Planning and tracking these tasks is micro-management.
These adaptations do not
compromise agility. They amplify it.
I'm not sure that the
Scrum Master role isn't always necessary, though. I agree that the coaching/process-leader role can become redundant when a team achieves the ability to self-organise. But the facilitator role that the
Scrum Master also fulfils remains important even within a
self-organising team.
Tags:
scrum,
adaptation
Links to this post
Agility and adaptation
Agility and adaptation go hand-in-hand. But when some organisations talk about agility they only talk about how agile methods need to be adapted to suit how they work.
To take root and deliver results, agility requires a fertile soil to grow in. Therefore, organisations also need to talk about how they will adapt to better accommodate agility and give it an honest chance of working.
Organisations must recognise that, more often than not, both their culture and structure need to change for (
uncompromised) agility to be achieved.
Tags:
adaptation,
change
Links to this post
Regular successes build momentum
Via
Agile Buzz ForumDave Churchville postulates that
continous small wins create energy and momentum and are ultimately responsible for the success of agile projects.
I agree. Without regular successes people become demotivated and unfocused. Visibility of progress disappears. And morale deteriorates as momentum is lost and the project drags on even more. It becomes a vicious circle.
Frequent delivery provides visibility of progress, early and often feedback, and creates recurring opportunities to
celebrate success. The success of delivering each iteration's worth of business value motivates the team to continue and improve. Seeing business value delivered reassures the
product owner that collaboration with the team is working and this encourages the
product owner to continue to steer the project effectively. All this helps to build a trusting relationship amongst everyone involved in the project.
Tags:
success,
trust
Links to this post
Go with the flow and find happiness
One of the great undiscovered joys of life comes from doing everything one attempts to the best of one's ability. There is a special sense of satisfaction, a pride in surveying such a work, a work which is rounded, full, exact, complete in its parts, which the superficial person who leaves his or her work in a slovenly, slipshod, half-finished condition, can never know. It is this conscientious completeness which turns any work into art. The smallest task, well done, becomes a miracle of achievement. - Og Mandido
Tom DeMarco describes flow as a highly productive and creative state of concentration. Mihaly Csikszentmihalyi describes flow as a sense of effortless action that provides enjoyment and ultimately happiness because your efforts are rewarded with learning and achievement. He goes on to say that it's possible to improve your quality of life by making sure that the conditions of flow are part of all your activities.
Here's a summary of Csiksczentmihalyi's components of flow, enjoyment and happiness:
1. The challenges of doing something that you have the chance of completing. If the challenge is too much for you then it's likely to make you anxious. If the challenge is insufficient you may become bored.
2. To help you enter flow and maintain concentration, identify a clear goal for your session and work incrementally, concentrating each increment on a limited field of attention.
3. Focus your awareness. Your actions and awareness will merge as you assimilate immediate feedback.
4. Immersion in flow removes the worries and frustrations of everyday life from your awareness.
5. Enjoyable experiences allow you to exercise a sense of control over your actions.
6. Concern for self disappears, yet paradoxically the sense of self emerges stronger after your session in flow has finished.
7. As you are immersed in flow your sense of time becomes distorted with hours passing in what seemed like minutes.
Further reading: Flow: The Psychology of Optimal Experience
Tags: flow
Links to this post
Anti the anti team
I'm so anti
the anti team.
Tags:
team
Links to this post
We're not limited by our abilities, but by our vision
Ralph Waldo Emerson said:
People only see what they are prepared to see. Try to see what is invisible to others. Recognise the hidden potential. Create a vision, believe in it and aspire to it.
But that's not enough.
W. Clement Stone said:
There is something more important than believing: Action! The world is full of dreamers, there aren't enough who will move ahead and begin to take concrete steps to actualize their vision. Have the
courage of your convictions. Be brave and take concrete steps to realize your vision.
Think about vision,
courage and taking action when someone says "Oh that wouldn't work here."
Tags:
vision,
courage
Links to this post
More on outsourcing
Ok. Outsourcing ... I said something like:
"Not to do it". Outsourcing can be made to work. But at what cost? Is it really a cost-effective alternative when you count the cost of the overheads it introduces? The 2 main issues I have with outsourcing relate to waste and the extra effort required to maintain effective communication.
1. WasteThe 7 wastes of software development can certainly be found in any situation but the following types of waste are amplified by outsourcing:
- Extra processing steps required to manage and co-ordinate exchanges with the other company
- Motion - finding information or chasing people at the other company (exacerbated by time zones)
- Waiting on the other company (exacerbated by time zones)
- Transportation - handing items (e.g. documentation, APIs or interfaces, software for integration or testing, test results, etc) over to the other company or receiving items from them
- Inventory - requirements specifications and other documentation, typically required by the contract with the other company
Motion, waiting and transportation are made worse by the inherent latency of dealing with an external party. Extra processing steps are about managing the dependency. Inventory is about you believing you can (and must) nail everything down at the start, for contractual purposes, and the other company covering its arse by being able to demonstrate that it has delivered what's written in black and white and then making money from your change requests. A lot of time is wasted when it could be spent producing working software in-house. And time is money so you're paying for it somewhere.
2. CommunicationCommunication is a value of agility. And your ability to understand, react and change quickly, and deliver business value depends on your ability to communicate effectively and continuously with everyone in the team and the product owner. Communication is always difficult but when people are collocated there are less problems to contend with. Of course you still have to work at it. Face-to-face communication is the most effective way to exchange information. When you can see a person you will pick up all sorts of valuable ancillary information from their facial expressions, hand gestures and body language. And don't forget osmosis. When everyone is sitting in the same office, or better still, the same bullpen, people will tune into information they deem important by filtering conversations happening around them. Important things like pair-programming, daily stand-ups, planning games, iteration reviews and retrospectives are simply more effective when everyone is in the same room.
When development or testing is performed externally there is a tendency to spec the hell out of everything. Specifications are an abstraction. Seldom does the written word truly express the author's thoughts. And when someone else reads the specification the words are interpreted according to that person's knowledge and understanding. It's very likely that the author and reader will end up with different mental models. And what's to say the author's thinking is right anyway? Do all the good ideas really happen at the start of a project, when the specification is being written? I don't think so. How can you be sure of everything up-front without trying things and getting some feedback? User stories provide reminders to have a conversation about the functionality required. They initiate collaboration between the product owner and the team, which reveals detail when it is needed. Writing specifications takes time and costs money. Why not spend the money in-house to develop working software in the time it takes to produce the specification document?
Maintaining effective communication is more difficult and requires more effort when people are distributed. Skype or Instant Messaging can help maintain conversation during, say pair-programming, but they don't help in daily stand-ups and the like. Video conferencing does but distance from the camera and transmission delay can obscure the non-verbal aspects of communication such as subtle facial expressions. Osmosis disappears. And again, time zones exacerbate the difficulties.
If things start to go wrong it's usually due to poor communications. So what do you do? Ironically, you agree with the other company that more face-to-face time is needed to improve communications and remove confusion. This means travel expenses increase.
Simplicity is a value of agility.
Keep it simple, stupid! Outsourcing is not keeping things simple. Everything becomes more difficult and requires more effort to sustain flow.
I alluded to this earlier: So often, the relationship with the other company is governed by the contract rather than being built on trust. This makes maintaining shared goals difficult and any differences may interfere with getting things done. In this situation, the other company may become sycophantic. They say what you want to hear even if they don't understand what you want or what you're saying. I'd be surprised if you get what you wanted in the time you wanted it.
Tags:
outsourcing
Links to this post
