memonic

Coaching,Mentoring:  Is there a difference?

Save
Coach, Mentor: Is there a difference?

In 1998 we conducted an on-line survey to define what partners felt were the attributes of effective mentoring relationships (see http://coachingandmentoring.com/mentsurvey.htm. A resounding YES came from responses to this open-ended question: Is there a difference between a mentor, coach, and supervisor? These differences are summarized in Table 1:

Table 1: Differences between Mentoring and Coaching

Mentor

Coach

Focus Individual Performance
Role Facilitator with no agenda Specific agenda
Relationship Self selecting Comes with the job
Source of influence Perceived value Position
Personal returns Affirmation/learning Teamwork/performance
Arena Life Task related

Coaching and Mentoring are not the same thing. Our results and experience support the conclusion that mentoring is a power free, two-way mutually beneficial learning situation where the mentor provides advice, shares knowledge and experiences, and teaches using a low pressure, self-discovery approach. Teaching using an adult learning versus teacher to student model and, being willing to not just question for self discovery but also freely sharing their own experiences and skills with the partners. The mentor is both a source of information/knowledge and a Socratic questioner. If I am your coach you probably work for me and my concern is your performance, ability to adapt to change, and enrolling you support in the vision/direction for our work unit.

Happiness Metric - The Wave of the Future

Save
Nöjd Crispare Historik
Update: ScrumInc used the happiness metric to help increase velocity over 300% this year. Net revenue doubled. The way to do this is now a formal pattern at ScrumPlop.org call "Scrumming the Scrum."


Traveling around the world, the happiness metric keeps bubbling up as a topic of interest. Books are starting to hit the charts at Amazon by business leaders (Zappos CEO, Joie de Vivre CEO) and psychologists. Managers and consultants are telling me that people are getting fed up with being unhappy at work. Younger people in particular are refusing to work in command and control environments based on punishment and blame. Major change is emerging (see The Leaders Guide to Radical Management by Stephen Denning).

The Scrum Papers documents some of the early influences on Scrum and Nobel Laureate Professor Yunus at the Grameen Bank in Bangledesh provided key insights on how to bootstrap teams into a better life. Practical work on these issues on the President's Council at Accion helped me put these insights into practice just prior to the creation of Scrum in 1993. I saw how to bootstrap developers out of an environment where they were always late and under pressure into a team experience that could change their life.

One of the most innovative companies in the world of Scrum is a consultancy in Stockholm called Crisp. Henrik Kniberg is the founder and we have worked together on Scrum and Lean for many years. He recently introduced the "happiness index" as the primary metric to drive his company and found it works better than any other metric as a forward indicator of revenue.


Henrik outlines on his blog how he used the A3 process to set the direction for his company and how that led to measuring company performance by the "Happy Crisper Index."


---------
Now a days one our primary metric is "Nöjd Crispare Index" (in english: "Happy Crisper Index" or "Crisp happiness index"). Scale is 1-5. We measure this continuously through a live Google Spreadsheet. People update it approximately once per month.

Nöjd Crispare Index

 Here are the columns:


  • Name
  • How happy are you with Crisp? (scale 1-5)
  • Last update of this row (timestamp)
  • What feels best right now?
  • What feels worst right now?
  • What would increase your happiness index?
  • Other comments
We chart the history and how it correlates to specific events and bring this data to our conference.

Nöjd Crispare HistorikWhenever the average changes significantly we talk about why, and what we can do to make everybody happier. If we see a 1 or 2 on any row, that acts as an effective call for help. People go out of their way to find out how they can help that person, which often results in some kind of process improvement in the company. This happened last week, one person dropped to a 1 due to confusion and frustration with our internal invoicing routines. Within a week we did a workshop and figured out a better process. The company improved and the Crisp Happiness Index increased.

Crisp Happiness Index is more important than any financial metric, not only because it visualizes the aspect that matters most to us, but also because it is a leading indicator, which makes us agile. Most financial metrics are trailing indicators, making it hard to react to change in time.

---------

As Dan Pink points out in his RSA talk, people are motivated by autonomy, purpose, and mastery. Takeuchi and Nonaka observed in the paper that launched Scrum that great teams exhibit autonomy, transcendence, and cross-fertilization. The "happiness metric" along with some A3 thinking helped flush out these issues at Crisp and it can work for your company.

At the core of the creation of Scrum was a daily meditation based on 30 years of practice beginning as a fighter pilot during the Vietnamese war. It is a good practice for a warrior and for Scrum as changing the way of working in companies all over the world is a mighty struggle. May all your projects be early, may all your customers be happy, and may all your teams be free of impediments!

"May all beings be well, may all beings be happy, may all beings be free from suffering."
- Compassion Meditation for a Time of War

Happiness Metric - The Wave of the Future

Agile over RUP, My Preferred Development Approach

Save

Agile over RUP, My Preferred Development Approach

In this post I thought I would describe my delivery approach of choice, in a brief, and (hopefully) understandable format.

As anybody who knows me can attest, I'm a big fan of agile development. That being said, I don't believe that agile alone is typically sufficient for me to successfully run all software delivery engagements. Although I always tweak the delivery approach I take to suit the conditions of a particular project, I frequently have relied on a combination of agile delivery combined with elements of the rational unified process (RUP). In a nutshell, the delivery approach I typically recommend for myself and my clients can be described as agile over RUP.


What does agile mean to me?
I have seen number different descriptions of what agile software delivery is and what it means to different people. The one that resonates the most with me describes agile development as:

1) a set of software development principles that emphasize:
  • individuals over process and tools
  • working software over documentation
  • collaboration over contracts
  • responding to change over following the plan

2) a set of complementary best practices that support these principles and are

  • collaborative
  • lightweight
  • simple

Note the "collection of complementary best practices" part of this definition, this is important (IMHO). In my experience agile is not something that is "done" or "not done". I've never understood the comment "we are doing agile delivery" or alternatively that team "isn't doing agile". Rather agile is something that can be applied to any development engagement on a graduated, practice by practice basis. When taken in isolation an individual agile best practice can still add value to a software development project. However, when an agile best practice is combined with and complemented with other agile best practices, there is a potential to provide an exponential amounts of value to the project.
These agile best practices come from a number of different but complementary agile "methodologies". Examples of these methodologies include SCRUM, XP, Crystal-Clear and the Agile Modeling Method. Increasingly, there is growing industry evidence that many organizations are selecting these best practices à la cart, rather than choosing a specific methodology and following it in its pure form. This is an approach that I follow, and it's one that I recommend...

Here is a brief list of the agile best practices that have provided value to delivery engagements I have been a part of in the past...

Test Driven Development


Test driven development is a development technique where test cases are written first, then the code necessary to pass the tests is implemented, and finally the software is refactored to accommodate changes. The availability of tests before actual development ensures rapid feedback after any change. "Refactoring" source code means modifying it without changing its behavior, and is sometimes informally referred to as "cleaning it up". Refactoring improves the understandability of the code and changes its internal structure and design, and removes dead code, to make it easier to comprehend, more maintainable and amenable to change. Many of the other tenets of agile development (like evolutionary design, responding to change, etc.) start to fall apart if application code is not supported by a robust and well thought out automated testing framework and periodic refactoring cycles.

Iterative Development

Another core best practice essential to effective agile delivery is the delivery of working software using a just-in-time assembly model where potentially shippable software is created at the end of each iteration. The first step in iterative development is to create a upfront but simple plan for the implementation effort as a whole, estimating and scheduling work into iterations of equal length ranging from one week to one month. At the beginning of each iteration a more detailed version of the plan is developed, scheduled work is completed, working code is presented to the business, progress is measured, and the plan is adjusted as necessary. For iterative development to truly work, software must be thought of as being potentially shippable at the end of each iteration. Work must also be focused on delivering real business value to the business, rather than developer "gold plating". Finally, estimates and planning needs to be done by the resources were actually going to do the work.

Daily Standup Meetings
Daily Standup Meetings is a core agile practice that requires a very little effort to run successfully. Communication among the entire team is the purpose of the daily standup meeting. A stand up meeting every morning is used to communicate problems, solutions, and promote team focus. Everyone stands up in a circle to avoid long discussions. It is more efficient to have one short meeting that every one is required to attend than many meetings with a few developers each. Organization and involvement of all levels of team members is encouraged by requiring each member to specify what they plan to accomplish the day before, what they actually accomplish, what they plan to accomplish today, and what, if anything is preventing them from being successful. On large-scale projects, hold "super daily standups" once a day to coordinate work across different teams. This super daily standup should be attended by one representative from each separate team.

Continuous Integration


Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including tests) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

Common Coding Standards And Self Describing Code

Coding standards tells developers how they must write their code. Instead of each developer coding in their own preferred style, they will write all code to a common standards. This makes sure that a large project is coded in a consistent style -- parts are not written differently by different programmers. Not only does this solution make the code easier to understand, it also ensures that any developer who looks at the code will know what to expect throughout the entire application. A typical supplementary best practice is to employ Self Describing Code, a set of coding conventions with the intent of making code a self-documenting artifact. Specific implementation patterns can be followed to ensure that code is developed with readability as a primary consideration, in effect reducing the need for code comments, supporting documentation, and other artifacts which may not always be kept up to date with production code.

Collective Code Ownership

Encourages every developer to contribute new ideas to all segments of the project. Any developer can change any line of code to add functionality, fix bugs, or refactor. Collective code ownership helps to mitigate the eventual transfer of resources from a particular project. This practice has been cited as being much more effective than conventional approaches such as code documentation, code walk-throughs and other knowledge transfer mechanisms.

Sustainable Pace


This best practice simply states that developers are much more effective at delivering high-quality code when they are put under the "right" amount of stress to perform. I.e. they are well rested, enthusiastic, and able to look at a problem with a fresh eye. This needs to be balanced with reasonably short term objectives, and a consistent and continual need to produce real results within a relatively short time. (I.e. a specific iteration)

Collaborative Modeling

Collaborative Modeling involves the use of simple and accessible tools to develop low fidelity, often throw away models of software that is to be built. The use of simple tools like index cards, whiteboards, and sticky notes allows for non-technical resources (i.e. the business) to actively partake in modeling HUP solution. Collaborative modeling calls for business users to actively engage and own any models that are developed to help guide the development.

An excellent example of collaborative modeling (one espoused by XP) are CRC cards (Class Responsibility Collaborator). CRC cards allow developers to create a low fidelity, object-oriented model. CRC models are created by laying out a set of index cards on a table or particle board, and labeling one or more of these cards with a major concept (a class) that needs to be represented in the software. Examples can include long-lived information such as a Student, an Account, or an Address. More temporary concepts can also be represented such as a ShoppingCart, or a RateCalculation. Using CRC modeling techniques facilitate a collaborative modeling atmosphere, one in which both business and technical resources can engage in.

Co-Located Teams

it is hard to overemphasize the amount of waste that is created by placing members of the same team in different locations. This should seem like a no-brainer, but the reality is many organizations really struggle with getting their team members into the same room for the duration of a project. Co-locating teams drastically reduces the need for official meetings, just go to the room where the work is being done, and resolve the issue. There is also a huge amount of information being simply from overhearing the conversation of others. On large-scale projects, organize teams to minimize the dependencies between teams and then make sure each team is in one room.

Retrospectives

While a set of best practices may look great on paper, the reality is that any best practice (even the ones described above) will require considerable refinement and adaption to the actual environment where the project is taking place. Retrospectives are short meetings held by the entire team at the end of every iteration. Retrospectives allow the team to add any best practices or processes that can help with the delivery of software, and remove one's that are getting in the way. Lessons learned are incorporated into the approach, and allow the team to continually improve over the duration of the project. Retrospectives are another essential agile best practice (IMHO) but one that is easy to implement.

Pair Programming


Pair Programming is a development technique involving the pairing of two developers to one computer, one mouse when keyboard. One developer enters in code (the driver) while the other developer (the observer) reviews, provide strategic direction, and refactoring suggestions. The two developers should switch roles for equally, a standard best practice is every 30 minutes. While seemingly simple, pair programming is (IMHO) probably one of the most difficult agile best practices to pull off, developers by their very nature like to work on their own computer on their own tasks. It is also counterintuitive to believe that their programming would not result in a drastic loss of productivity. There is actual empirical evidence that this is the case, with some studies showing overall effort reduced by 15% and code quality being increased by 50%. Pair programming also makes it incredibly easy to onboard and offboard resources, increases developer discipline (someone's always watching over somebody else) and lead to more effective problem-solving.

Active Business Stakeholder

Every form of agile methodology has some notion of this practice. XP calls the on-site customer, SCRUM calls it a product owner. In all instances, some form of user, or user proxy, plays an active part of the development team, providing advice, direction, and knowledge of what the product should do. The active business stakeholder is responsible for developing all requirements for the system, and has the final say on priority. The active business stakeholder is empowered to make decisions on the fly, and serves as a buffer between the development team and other business stakeholders.

Given the list above, the set of agile best practices could also be represented as:


Agile itself could be represented as a set of agile principles and agile best practices...



stay tuned for part 2 of this presentation where I described how RUP fit into the picture...

About Planning Poker ® Cards

Save

About Planning Poker® Cards

Mountain Goat Software offers Planning Poker® cards for your use in estimating. Each deck contains enough cards for four estimators to each hold cards with the following values: ?, 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, and ∞. The cards are printed on the finest quality card stock available. Each deck comes in a box to help keep the cards from being damaged.

$2.50

Planning Poker Cards For Everyone

Save
Planning Poker Cards For Everyone

I thought this would be useful "swag" for any teams out there starting Agile estimating techniques or any teams who want to improve at estimating development tasks.  I'm not going into the details of how it's done, you can read for yourself http://www.planningpoker.com/detail.html. I first read about planning poker in Mike Cohen's book Agile Estimating and Planning. You can also get actual planning poker cards from his company's web site http://www.mountaingoatsoftware.com/products/planning-poker-cards, what a great idea!

Back when our team was learning Agile estimating I had these documents made to help us play planning poker. I thought these would be useful to anyone in the learning phase or wants some tools that can help with the process. So here it is, FREE planning poker cards that you can take to your favorite print shop and get printed (download the attached PDF's).

Planning-Poker-Playing-Cards-pg01_front  Planning-Poker-Playing-Cards-pg01_back

Planning-Poker-Playing-Cards-pg02_front  Planning-Poker-Playing-Cards-pg02_back

 

PDF 1 Link - Planning Poker Page 1 Front

PDF 2 Link - Planning Poker Page 1 Back

PDF 3 Link - Planning Poker Page 2 Front

PDF 4 Link - Planning Poker Page 2 Back

 

Then I took this one step further and made use of our company's business cards which needed to be reprinted anyways! Instead of just getting new business cards printed, why not take this opportunity to make planning poker cards out of them? Dual purpose Agile business cards! The front of the cards have the generic company branding as well as the individual contact information. The back of the cards have our division brand (ThirdAngle) and a unique number used for estimating. It's also a good conversation starter when you give out your business cards :-).

Agile Business Cards

 

Next time you see the team you'll have to ask for each of us for our business cards so you can have the set.