Skip to content

Blogs

Situational Leadership and the ScrumMaster

Agile Game Development - Fri, 04/04/2014 - 20:11
After I recently posted an article called "An Introduction to Situational Leadership", I was contacted by Randy Baker.   Randy lived nearby and had worked with Dr. Paul Hershey, the developer the initial Situational Leadership (SI) model, for 20 years.

In the original article, I shared an illustration of the levels of team maturity:

I described to Randy, how the ScrumMaster role is meant to help teams reach higher levels of maturity by, at first, directing less and then delegating more.  Randy then drew the following diagram (it was, literally, on a Starbucks napkin so I've redrawn and added it to the diagram above):
The diagram shows the relationship between a leader in the SI model and the team, based on their maturity.  This diagram resonates because it matches the formations you'd observe in a Daily Scrum based on the maturity of the Scrum Team.
Scrum attempts to bootstrap a Scrum Team into the "high supportive behavior" side (top half).  Very often a studio's culture will be more directive going in, and you'll initially find teams reporting to the ScrumMaster, who is running the meeting (the "Coaching" quadrant in the upper right) at the center of a group of developers.  Over time, a good ScrumMaster will improve their facilitation skills and support (upper left quadrant) the team as an equal member, standing as a part of the team's circle.
As a Scrum Team develops their maturity and becomes more self-organizing, the ScrumMaster will delegate more of their day-to-day duties, but always observe and support the team (lower left quadrant).
Any team that finds themselves in the lower right quadrant is not "doing Scrum" yet.
Categories: Blogs

Minor Update: Seven Essential Teamwork Skills

Learn more about our Scrum and Agile training sessions on WorldMindware.com

I was recently checking my Google Analytics for Agile Advice and the article I wrote quite a while back in 2009 about teamwork skills is even more popular than the front page of this blog!  I took a look at it and made some tweaks including providing some good references for more information about each of the teamwork skills.  Take a look: Seven Essential Teamwork Skills.  The only hard one was to find a good article about “sharing” as a teamwork skill.   If you know of one, please comment so that I can add it!  I’ll even be happy to take a link to an article you have written yourself.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories: Blogs

Authority and Power

Complex and Agile - Joseph Pelrine - Fri, 04/04/2014 - 13:06

One of the classic sayings in Scrum is that the ScrumMaster has no authority. He cannot tell his team members what to do, or what not to do. In a way, this makes sense. If the ScrumMaster had the authority to tell people what to do, he would take away their opportunity to take responsibility for their actions, to become committed and not just involved. Looking at it differently, by telling team members what to do, he would give them the chance to refuse responsibility for their actions. “It’s not my problem, he told me to do it!” Even though the ScrumMaster has no authority, this does not mean that he has no power.

Power cannot be taken, it can only be given. A person only has power over you if you give them this power over you. Being aware of the ways you give people power over you will help you avoid doing it unintentionally or inadvertently. So, what types of power may a person possess, and which types of power should one best focus on increasing?

In 1959, John French and Bertram Raven wrote a seminal paper on the different types of power (1959). According to French and Raven, power is defined as the potential ability of one person to influence another person. Thus, power is potential influence, while influence is kinetic power.

In their paper, French and Raven define five different types of power, all of which may vary in their domain, strength and range.

Reward power. You gives a person reward power over you when you believe that they can do something good for you or they can take away something bad. Obviously, if the person actually does do something good for you, his or her reward power over you increases.

Coercive power. You give a person coercive power over you if you believe that the person can do something bad to you, for example, cause you harm or pain. If the person actually does something bad to you, their power over you increases. The mere awareness or threat of coercive power is often enough to enforce compliance. Imagine if you were driving a car and you saw a police officer standing on the corner. Even if he was not looking directly at you, you would tend to drive slower.

Legitimate power. You give a person legitimate power over you if you believe that they have the right to have this power. This right often comes as the result of an implicit or explicit social contract. An example for an implicit social contract would be a contract that parents have with their children (although as every parent knows, this contract must be renegotiated regularly). An explicit social contract would be your work contract, which gives your boss power over you. As one can see, legitimate power contains both reward and coercive components. If you do something good at your job, you may get a bonus. If you do something bad at your job, you may get fired.

Expert power. You give a person expert power over you if you believe they have superior knowledge relevant to the situation and to the task at hand. This power rarely extends outside of the domain of expertise, but the implied transference of expert power into other domains is a technique often used in advertising.

Referent power. Referent power is the most difficult type of power to describe. It is best understood as a type of power that comes from personal integrity and/or from charisma. This is the type of power that Gandhi or Nelson Mandala or Martin Luther King had. Over time, though, the power these men had became legitimate power, as they were voted into political office.

In his later works, Raven added a sixth type of power, which he termed informational power. Having access to information, and the ability to use this information, can give a person power. As an example, think of Edward Snowden.

Looking at the different types of power, one sees that they can be grouped into two groups – positional power, which is power one receives as the result of being in a position to have the power, and personal power, which is not dependent upon position, but solely dependent upon the person. If you want to increase your power base, in order to better help people, then which type(s) of power should you focus on increasing?

Being in a position to give a reward or to coerce, or being in a position of having the right to legitimate power, puts one in the position to command others. This is not the type of power a ScrumMaster should use. This is the reason why no one who is in a management position can be a ScrumMaster for his team. It is better to focus on increasing your personal power than on increasing your positional power.

How can you start increasing your personal power? You can increase your expert power by concentrating on your continued professional development. Reading, keeping up to date on new developments in your field, attending trainings, etc., are all ways of increasing your expert power.

Increasing your referent power can be done by focusing on your continued personal development. This is a noble task whether or not you work as a ScrumMaster, since furthering your personal competencies will increase your feeling of well-being. Awartani et al. (2008) define well-being as the realisation of one’s physical, emotional, mental, social and spiritual potential.

Mental or rational well-being as that part of life which is primarily related to thinking and cognition, and to the processes of the rational mind, e.g.: planning, understanding, focusing, envisioning, abstraction, reflection, evaluation.

Emotional refers to the intrapersonal or inward-looking awareness and processing of feelings, of understanding your feelings, their triggers, and your reaction patterns, of having your emotions under control, and not being “hijacked” by them.

Social refers to the interpersonal or outward-looking awareness and processing of feelings, of understanding how they influence our interactions with others.

Physical refers to those aspects of life related to the physical senses and to sensory experience, to our bodies, and to the material and natural environments. The actions and functions of doing, building, taking apart, detailing, producing, acting, and making practical are included.

Spiritual is not necessarily a religious or esoteric concept, but refers to life, to its meaning and purpose, to beliefs and what one believes in. You are believable for others when they feel that you believe deeply and strongly in something.

Although all these aspects each play a role, well-being represents a pervasive feeling about oneself, one’s life, and one’s environment. You can start right now and take a first step towards your own well-being. Take a few moments to think about these 5 areas, where your strengths and weaknesses are, and which areas you want to focus on strengthening.

References

Awartani, M. et al. (2008) Developing Instruments to Capture Young People’s Perceptions of how School as a Learning Environment Affects their Well-Being. European Journal of Education, 43, 51-70.
French, J.R.P.Jr. & Raven, B. (1959) The Bases of Social Power. In Studies in Social Power, Ann Arbor, Michigan: Institute for Social Research, University of Michigan, pp. 150-167.

Categories: Blogs

April, April, Angsthase

Scrum 4 You - Fri, 04/04/2014 - 12:52

Der Aprilscherz ist beliebt wie eh und je. Doch während man im Privaten nach wie vor auch sein liebstes Gegenüber genussvoll ins offene Messer laufen lassen darf, lassen die meisten Medien dieser Tage eine geradezu panische Angst erkennen, man könne ihre ohnehin zumeist recht harmlosen Aprilscherze auch nur für Augenblicke ernst nehmen. Zeitungsmeldungen im schnellebigen Internet werden mit einem durch Kursivierung korrekt als redaktioneller Hinweis ausgewiesenen „April, April“ unterschrieben, Nachrichtensprecher erklären dem erstaunten Zuschauer mit geschäftsmäßigem Lächeln, er sei vermittels des eben gesendeten Einspielfilms in den April geschickt worden.

Ganz unzweifelhaft ist das Schönste an jedem Aprilscherz doch der Moment, in dem man mit einem herzlichen „April, April!“ sein Opfer darüber belehren kann, überhaupt ein Opfer zu sein. Wer labt sich nicht gerne an dieser ergötzlichen Ungläubigkeit, garniert mit einem Quäntchen peinlicher Berührtheit? Aber dazu muss der Scherz doch erst einmal glaubhaft gemacht worden sein! Das ist doch der Witz am Witz! Hier ist von Stunden, vielleicht nur Minuten die Rede, die es zum Einsickern der Fehlinformationen in die Opferhirne braucht.

Man mag in aller Breite und Ausführlichkeit über die Ursachen dieser Entwicklung im öffentlichen Raume raisonnieren, im Endeffekt aber wird es sicherlich darauf hinauslaufen, dass an verantwortlicher Stelle die akute Sorge besteht, irgendjemand könnte sich ohne unmittelbare Scherzaufklärung möglicherweise in irgendeiner Weise auf den Schlips getreten fühlen. Was aber tun?

Auf Scrumdeutsch: Commitment muss her! Wozu ist denn ein witzloser Scherz gut? Wer andere in den April schicken will, muss auch die Möglichkeit verantworten können, dadurch nicht nur positive Reaktionen auszulösen. Das ist im Voraus zu bedenken: Was für einen Scherz will ich haben? Wie wird er durchgeführt? Was will ich erreichen? Doch ist der Plan einmal gefasst und die Entscheidung getroffen, muss die Sache konsequent durchgezogen werden, denn jemanden fast in den April geschickt zu haben, ist genauso viel wert wie fast funktionierende Software oder ein fast fahrendes Auto.

Related posts:

  1. ScrumAlliance introduces Examination for CSM and CSPO
  2. 15 Minuten sind 15 Minuten
  3. Chinesen essen doch Reis :)

Categories: Blogs

News update 2014/04 – The Drama Triangle

ScrumSense.com - Peter Hundermark - Fri, 04/04/2014 - 12:29

Interested in knowing more about what the Drama Triangle is all about? Dillon Weyer of Scrum Sense discusses the Drama Triangle and how it can be used to help deal with team conflict and problem solving. Follow this link to find out more….. Kanban Foundation Level Training There are only THREE seats remaining on our Kanban Foundation Level Training […]

The post News update 2014/04 – The Drama Triangle appeared first on ScrumSense.com.

Categories: Blogs

The Dangerous Lite Side of Mindfulness and Lean

Evolving Excellence - Fri, 04/04/2014 - 08:27

By Kevin Meyer

I’ll preface this post by saying that yes, I’m from crazy California, I eat granola with fruits and nuts in the morning, am vegetarian (well, pescatarian), dislike wearing shoes, and practice yoga. At least I don’t have dreadlocks – yet. So there – now you’re warned.

I’m currently winging my way over to Hawaii’s Big Island, probably my favorite U.S. destination, and a place I’ve been to a few times a year for over a couple decades – including only three weeks ago. It’s a special place for me and especially my wife, who was born in Hilo and then eventually married me in Makena. Unfortunately this trip isn’t really for pleasure as we’ll be scattering the ashes of both of my wife’s parents, who long ago went to Hawaii on their honeymoon… and quit their jobs and just stayed. Yes, it’s that kind of place. I guess in a way we’re experiencing the circle of life, and perhaps this time closing one of its intricate loops.

Long-time readers will remember that years ago I would often escape to Hawaii on my own for a couple days to decompress and recalibrate. Solitude, silence, and the sea can do wonders when life is throwing some incredible work and personal chaos at you, as it was at me.

This is where I discovered the concepts and power of Zen, where I read Matthew May’s The Shibumi Strategy that tied it all together, and where I became human again. The chaos that had enveloped me had turned me into a bit of a neurotic mess. I created contingency plans A, B, C, and D for every possible business and personal situation, spending far more time and energy creating those multiple redundant backup plans than it would have taken to simply recover from the rare occurrence when something actually did go wrong. Learning to be mindful helped put the world into proper perspective, created a calm mind and being, thereby freeing up a tremendous amount of energy.

On the plane I’m listening to Brian Eno’s Music for Airports, a great album for calming the mind, and contemplating a couple of recent articles on mindful leadership. I’m a little concerned.

Just as lean is much more than 5S and value stream mapping, mindfulness is much more than simply being aware as a leader. A lean “transformation” based on simply implementing a set of common lean tools, without realizing it’s a holistic management system, will inevitably fail. Some lean consultants and writers, perhaps angling for the quick buck or out of ignorance, have focused on the tools at the expense of the system. Now I fear we’re seeing the same with mindfulness.

A couple days ago Maria Gonzalez wrote a piece for HBR titled Mindfulness for People Who Are Too Busy to Meditate. It’s a good article, and I agree with many of the techniques, and especially the benefits.

For instance, researchers have found that mindfulness can reprogram the brain to be more rational and less emotional. When faced with a decision, meditators showed increased activity in the posterior insula of the brain, which has been linked to rational decision making. This allowed them to make decisions based more on fact than emotion. This is good news since other research has found that reasoning is actually suffused with emotion. Not only are the two inseparable, but our positive and negative feelings about people, things, and ideas arise much more rapidly than our conscious thoughts, in a matter of milliseconds. We push threatening information away and hold friendly information close. We apply fight-or-flight reflexes not only to predators but to data itself.

She goes on to describe a concept of “micro meditation” for those who don’t want to practice full meditation. I also use “micro meditation” to re-center throughout the day. Taking just a minute to become aware of my breathing, the feeling of the steering wheel beneath my hands, or the sounds when the car radio is turned off. Just being truly aware in the moment, of your senses and emotions, without thinking about projects, people, things – or the past or the future. A minute or two is obviously easier than a full 20 to 30 minutes each morning.

As with tool-based lean, it works – temporarily and superficially. But it’s not transformative. To become truly aware and present in the moment, long term, takes a lot of very hard work. Micro meditation, as with the individual tools of lean, is just a tool. It supports the larger concept, but it is not the larger concept itself. Last week there was also an article in The Wall Street Journal on Khajak Keledjiano, CEO of Intermix, now part of Gap. Mr. Keledjiano discovered mindfulness and meditation on a dare.

A friend bet Khajak Keledjian $15,000 six years ago that he wouldn't be able to sit still for 15 minutes in complete silence. After nearly five months of trying, the 41-­year-­old CEO of high-­fashion retailer Intermix couldn't do it.

Real meditation is not just silence, it’s purposely not thinking about projects or people, the past or the present. Silencing the mind to become aware of underlying thoughts, emotions, environment, and perspectives. And it is incredibly difficult – it took me two months before I could successfully count ten breaths without my mind going off on a tangent with other thoughts. Counting ten breaths is the most basic exercise. It took a year to build my meditation practice from 5 to 10 to now 20 minutes. Here’s an introductory article, and a short but much deeper one from a more Zen Buddhist perspective. To a Buddhist, even real meditation is just a tool of a much larger belief system.

Many confuse meditation with prayer. It’s completely different – but they are very complementary. My morning practice has four components: a twenty minute (and I still struggle) period of meditation to clear the mind and become aware in the present. Then a few minutes where I focus purely on gratitude for family, friends, and blessings. That sets the stage – and perspective - for a period of prayer. Amazing how little you need to ask for when you’re present in the moment and realize how much you already have to be thankful for. Prayer then becomes focused outward, as it should be. Finally, I end with a couple minutes identifying my top two to four projects for the day. In the evening, just before bed, I usually take time for a couple minutes of hansei – reflection – on how I did with those goals and how I can improve, then a couple minutes of meditation to calm the mind, then sleep.

If you simply pause a moment to count a breath or two you don’t realize how much hard work it takes to become truly aware in the present – every moment. And, as with lean, it is still a never-ending journey – both to continually reinforce and sustain, and to improve and grow. You can easily identify someone who doesn’t get lean because they say they’ve “done lean.” The same with being mindful. You don’t “do” or become mindful – you’re continually working very hard at it.

Mr. Keledjian does work hard at it. Even with an incredibly busy schedule he makes his morning practice a priority, which is something I still struggle with. To reinforce the personal practice he takes classes at least once a week, and goes on a retreat once a year. He’s also diving into Kundalini – the yoga of the mind – and something I’ve just recently started to explore.

Mindfulness, and mindful leadership, is becoming very popular as the benefits become better known. It’s taught at the leading business schools, in the military, and on the sports fields. That’s great. But just as lean has sometimes been simplified to a set of tools in order to grab the quick short-term win at the expense of a long-term, sustained transformation, quick-and-easy mindfulness has a similar risk.

Real transformation is a journey that takes hard work and perseverance… forever.

Categories: Blogs

The Dangerous Lite Side of Mindfulness and Lean

Evolving Excellence - Fri, 04/04/2014 - 08:27

By Kevin Meyer

I’ll preface this post by saying that yes, I’m from crazy California, I eat granola with fruits and nuts in the morning, am vegetarian (well, pescatarian), dislike wearing shoes, and practice yoga. At least I don’t have dreadlocks – yet. So there – now you’re warned.

I’m currently winging my way over to Hawaii’s Big Island, probably my favorite U.S. destination, and a place I’ve been to a few times a year for over a couple decades – including only three weeks ago. It’s a special place for me and especially my wife, who was born in Hilo and then eventually married me in Makena. Unfortunately this trip isn’t really for pleasure as we’ll be scattering the ashes of both of my wife’s parents, who long ago went to Hawaii on their honeymoon… and quit their jobs and just stayed. Yes, it’s that kind of place. I guess in a way we’re experiencing the circle of life, and perhaps this time closing one of its intricate loops.

Long-time readers will remember that years ago I would often escape to Hawaii on my own for a couple days to decompress and recalibrate. Solitude, silence, and the sea can do wonders when life is throwing some incredible work and personal chaos at you, as it was at me.

This is where I discovered the concepts and power of Zen, where I read Matthew May’s The Shibumi Strategy that tied it all together, and where I became human again. The chaos that had enveloped me had turned me into a bit of a neurotic mess. I created contingency plans A, B, C, and D for every possible business and personal situation, spending far more time and energy creating those multiple redundant backup plans than it would have taken to simply recover from the rare occurrence when something actually did go wrong. Learning to be mindful helped put the world into proper perspective, created a calm mind and being, thereby freeing up a tremendous amount of energy.

On the plane I’m listening to Brian Eno’s Music for Airports, a great album for calming the mind, and contemplating a couple of recent articles on mindful leadership. I’m a little concerned.

Just as lean is much more than 5S and value stream mapping, mindfulness is much more than simply being aware as a leader. A lean “transformation” based on simply implementing a set of common lean tools, without realizing it’s a holistic management system, will inevitably fail. Some lean consultants and writers, perhaps angling for the quick buck or out of ignorance, have focused on the tools at the expense of the system. Now I fear we’re seeing the same with mindfulness.

A couple days ago Maria Gonzalez wrote a piece for HBR titled Mindfulness for People Who Are Too Busy to Meditate. It’s a good article, and I agree with many of the techniques, and especially the benefits.

For instance, researchers have found that mindfulness can reprogram the brain to be more rational and less emotional. When faced with a decision, meditators showed increased activity in the posterior insula of the brain, which has been linked to rational decision making. This allowed them to make decisions based more on fact than emotion. This is good news since other research has found that reasoning is actually suffused with emotion. Not only are the two inseparable, but our positive and negative feelings about people, things, and ideas arise much more rapidly than our conscious thoughts, in a matter of milliseconds. We push threatening information away and hold friendly information close. We apply fight-or-flight reflexes not only to predators but to data itself.

She goes on to describe a concept of “micro meditation” for those who don’t want to practice full meditation. I also use “micro meditation” to re-center throughout the day. Taking just a minute to become aware of my breathing, the feeling of the steering wheel beneath my hands, or the sounds when the car radio is turned off. Just being truly aware in the moment, of your senses and emotions, without thinking about projects, people, things – or the past or the future. A minute or two is obviously easier than a full 20 to 30 minutes each morning.

As with tool-based lean, it works – temporarily and superficially. But it’s not transformative. To become truly aware and present in the moment, long term, takes a lot of very hard work. Micro meditation, as with the individual tools of lean, is just a tool. It supports the larger concept, but it is not the larger concept itself. Last week there was also an article in The Wall Street Journal on Khajak Keledjiano, CEO of Intermix, now part of Gap. Mr. Keledjiano discovered mindfulness and meditation on a dare.

A friend bet Khajak Keledjian $15,000 six years ago that he wouldn't be able to sit still for 15 minutes in complete silence. After nearly five months of trying, the 41-­year-­old CEO of high-­fashion retailer Intermix couldn't do it.

Real meditation is not just silence, it’s purposely not thinking about projects or people, the past or the present. Silencing the mind to become aware of underlying thoughts, emotions, environment, and perspectives. And it is incredibly difficult – it took me two months before I could successfully count ten breaths without my mind going off on a tangent with other thoughts. Counting ten breaths is the most basic exercise. It took a year to build my meditation practice from 5 to 10 to now 20 minutes. Here’s an introductory article, and a short but much deeper one from a more Zen Buddhist perspective. To a Buddhist, even real meditation is just a tool of a much larger belief system.

Many confuse meditation with prayer. It’s completely different – but they are very complementary. My morning practice has four components: a twenty minute (and I still struggle) period of meditation to clear the mind and become aware in the present. Then a few minutes where I focus purely on gratitude for family, friends, and blessings. That sets the stage – and perspective - for a period of prayer. Amazing how little you need to ask for when you’re present in the moment and realize how much you already have to be thankful for. Prayer then becomes focused outward, as it should be. Finally, I end with a couple minutes identifying my top two to four projects for the day. In the evening, just before bed, I usually take time for a couple minutes of hansei – reflection – on how I did with those goals and how I can improve, then a couple minutes of meditation to calm the mind, then sleep.

If you simply pause a moment to count a breath or two you don’t realize how much hard work it takes to become truly aware in the present – every moment. And, as with lean, it is still a never-ending journey – both to continually reinforce and sustain, and to improve and grow. You can easily identify someone who doesn’t get lean because they say they’ve “done lean.” The same with being mindful. You don’t “do” or become mindful – you’re continually working very hard at it.

Mr. Keledjian does work hard at it. Even with an incredibly busy schedule he makes his morning practice a priority, which is something I still struggle with. To reinforce the personal practice he takes classes at least once a week, and goes on a retreat once a year. He’s also diving into Kundalini – the yoga of the mind – and something I’ve just recently started to explore.

Mindfulness, and mindful leadership, is becoming very popular as the benefits become better known. It’s taught at the leading business schools, in the military, and on the sports fields. That’s great. But just as lean has sometimes been simplified to a set of tools in order to grab the quick short-term win at the expense of a long-term, sustained transformation, quick-and-easy mindfulness has a similar risk.

Real transformation is a journey that takes hard work and perseverance… forever.

Categories: Blogs

Organizing a small-ish company to do Scrum and ‘regular work’

Agile & Business - Joseph Little - Fri, 04/04/2014 - 03:55

Holly asks: “I am relatively new to this methodology, but I would say I would like to learn more about how resources are assigned to Scrum teams.  Resource allocation – do Sprint team members need to spend 100% of their time in a Scrum Team?  If so, how do we account for existing job responsibilities?”

***
Good question or questions.

In simple terms, we are dying from complexity.  So, we want to keep things as simple as possible, to help people become more productive.

This is what I am thinking from what I know so far of your situation.  Imagine that your company has 800 employees, but most are ‘in the field’.  So, you have 75 people who support ‘BAU’ (business as usual), who are not ‘in the field’ and so are also potentially available to support Innovation.  And, to some degree, do need to support Innovation.

So, for 125 of the BAU people, I would have a rule that they are 80% dedicated to BAU and each person can use up to 20% of their time to support ‘innovation’.

I would maybe move 25 of the current BAU people to an Innovation group, which would include other people already doing innovation (technology people, project managers, etc.).  Then we call this the group of people doing ‘Innovation’ or ‘Change’, which now has about 75 people.

Let’s assume my ratios of BAU and Innovation people is roughly factually correct for now.  For example, it provides enough hours to do the related BAU work (if 20% of their time is also given to Innovation).  But it still raises two questions:
(a) is this the optimum ratio?
(b) should the firm be investing more (or less) in Innovation?

These two questions should be of prime interest to the Exec Team.

Note that often the Innovation people are doing work to benefit the BAU people, directly or indirectly.

These are the two main groups.  Note that the innovation people include business people also.

I would form most of the people in Innovation into Scrum Teams.  But the BAU people are NOT part of the Scrum Teams. At least not as ‘pigs’, although they may work with the Scrum Teams some as chickens (in their 20% time).

And we would group work into ‘Product Backlogs’ that have groupings of stuff that can be released quickly.  And we get a limited number of ‘projects’ or product releases in flight at any one time. In simple terms, one project per Scrum Team (per 7 people in a Scrum Team).

Obviously, we can only support, with the Innovation people that we have, a limited number of product releases at any time (in any year).

Each Innovation person is 80% dedicated to one Team (but can advise others with 20% of their time).  And the Innovation people are 100% innovation…no meaningful BAU responsibilities.  They can ‘advise’ others on BAU work in their 20% time.

It may be that some lower priority projects will ‘require’ some BAU people to be involved. But a lower priority project can only start if someone feels that they can get enough BAU support to be viable.  Or can get enough ‘business support’ elsewhere (within Innovation, via consultants, whatever).  And this will not be the case; this may represent a significant constraint on the number of inflight Innovation teams. So that some projects will be blocked until higher priority projects complete, and ‘release’ certain BAU people.

So, X project may not be able to start.  The Exec Team can decide to hire people or not, to fix that impediment.  Or, we go to the next viable priority project.  (Remember that business information can get into a Team either from Innovation people (eg, product owners or BAs or whatever we call them) or from BAU people.

Why?  We need to be focused on getting things DONE, not on how much work is ‘in process’.  We need to be focused on clear accountabilities by Team. Each Scrum Team is focused on only the one next release.  (That means the release is much more likely to get done well and quickly.)

How to form the Teams?  Here is a good option.  Have 3 managers draft up a set of teams.  And let all the Innovation people look at that and then ‘self-organize’. They can modify the proposal.  Maybe give the Innovation people a week to meet and discuss and change the proposed teams.  With the understanding that any person in a Team is 80% dedicated to that one Team, at least.  And then the 3 managers get to review the alterations and give final approval.  But the group usually does a very good job.

Usually later we discover a few things, and realize we need to make some adjustments, but the Teams usually can manage that.

The real issue is when to start and stop ‘projects’.

Whenever we have a better project than one currently in flight, we need a way to start to pause the existing project (or get it to release early) and start the higher value project. Before pausing a project, we tell the related Team, and ask them ‘we want to ‘pause’ your project…can you release most of what you have now ‘real soon’?  How soon?’  And then adjust according to their advice.

Another issue is: when does the ET know that a Scrum Team is coming ‘free’?  I give the Scrum Teams the responsibility to ‘brag’ about a Release that they are about to put out.  And they are clearly expected to release quickly, and also to release high value and high quality products.

So, when a Team has just released, it is also a time when the ET can give the Team a different ‘assignment’ or ‘mission’.  The Team may make a case that they need to stay on Product1 for the next release.  But the ET gets the final decision.

So, in this vision, the main jobs of the ET are two (for the innovation teams) 1. Fix impediments 2. Be decisive about priorities.

This last includes….when a Team finishes a release, what do we give them next?

Given where we have come from, I suspect the Team will have to say (probably repeatedly for awhile): “We are only working on one and only one release at a time…the top priority one.”

 

twittergoogle_plusredditlinkedinmail
twitterlinkedinrss
Categories: Blogs

Learnings from the Toronto Scaling Workshop

Agile & Business - Joseph Little - Fri, 04/04/2014 - 03:14

Last week we had a Scaling with Agile Workshop in Toronto.

More and more I am convinced that this scaling workshop is necessary for many people to figure out how to do Scrum well in their business situation.  They just need to work through how they will make it work in their context.  And many of the problems have to do with ‘scaling’.

Of course, not every person or team or company has ‘scaling’ problems.  So, ‘scaling’ solutions do not need to be included with Scrum (for everyone).  And of course these scaling issues vary widely and differ from situation to situation. Often in the same company.

We like to define scaling and the related words precisely.  Scaling as such, to me, is really limited to having 3 or more Scrum Teams working together on one Product.  (We use other words for the other problems that often come along with scaling or are included in ‘scaling’ by some people.)

Scaling, as we define it, still is a common problem. Often, as just suggested, many other problems come along with it. Cultural change, agile transformation, distributed scrum, etc, etc.

In the Workshop, we gave the attendees a basic framework, and an approach to defining their problems.  We tried to focus on scaling proper, but we also took questions and issues with ‘scaling’ more broadly defined.  We took their real issues.

It was impressive how different the real problems were.  Yet both were ‘scaling’.

To give them background, we discussed patterns, we discussed ScrumPLOP.org, we discussed basic and classic Scrum patterns; we discussed LeSS, and we discussed SAFe.  The key concept is: how do we try simple patterns that fit the specific needs that your situation has?  And see if we can make some progress today, and not make things overly heavy or complex.

It was impressive how, with a few key concepts, they could easily design solutions to most of their pressing problems.

One last key concept.  The real energy is inside the Team.  All the bright people running all the scaling stuff do not add any value directly. At least so far as  the customer can tell.  They may be necessary, but not essential.  So, maybe you divert some energy from the Team(s) to the ‘Scaling stuff’ for some temporary time.  But remember to focus again soon on the Team(s). Remember that the real power of scrum is in the Teams.

twittergoogle_plusredditlinkedinmail
twitterlinkedinrss
Categories: Blogs

Halifax: Public Impediment List

Agile & Business - Joseph Little - Fri, 04/04/2014 - 01:00

As some of you know, I am a strong proponent of aggressively attacking the impediments. And I think it starts with a good public impediment list.

So, as examples, here are the impediments identified by the class in Halifax.

  1. Team is working on too many things
  2. No prioritized backlog
  3. Uninvolved PO
  4. Keeping everyone in the loop (not)
  5. Complexity
  6. Lack of management attentiveness
  7. Acting on retrospective improvements
  8. PO not involved
  9. Lack of understanding
  10. Silo workers
  11. Lack of impediment list
  12. Lack of retrospective
  13. Increasing Tech Debt
  14. Not having vision from PO
  15. Managing people instead of work
  16. Lack of team spirit
  17. Managing interference
  18. Unmotivated
  19. Bottom down planning
  20. Too much useless chatter (from Mgmt, I think)
  21. Lack of early feedback
  22. No ending [to] project
  23. Not following process
  24. Conflicts (too much)
  25. Keeping Top 20 impediments
  26. Distributed team
  27. Lack of process
  28. Lack of management
  29. Communication
  30. Too many cooks
  31. Product knowledge gap
  32. Scope creep
  33. Not defining DOD
  34. Lack Buy-in
  35. Lack of process for Development Tasks
  36. Technology group (IT) support infrastructure
  37. Testing Time
  38. Bug fixing time
  39. Not having all Scrum activities
  40. Management available
  41. Lack of communication
  42. Poor planning
  43. No estimates (no velocity)

 

twittergoogle_plusredditlinkedinmail
twitterlinkedinrss
Categories: Blogs

Tennis coaching , Halo effect and celebrity bias

Agile World - Venkatesh Krishnamurthy - Thu, 04/03/2014 - 22:09

One of my friends is a very successful  tennis coach, however, he sends his kids to a different coach.  This was interesting, and I asked him why can’t he teach his kids. His response didn’t surprise me at all. He said, kids take parents for granted and some times, they listen to outsiders more intently.

I see a similar pattern at work as well.  Some times, employees listen to a highly paid external consultant rather than an in-house expert or supervisors.

Why is that ?

I googled around to find some research or articles around this kids behavior, and I found this interesting article.  The author gives the following 3 reasons behind kids behind deaf to their parents:

  • Biggest Reason #1 - You don't listen to them.
  • Biggest Reason #2 - You don't do what you say you're going to do.
  • Biggest Reason #3 - You don't keep the commitments you make.

Applying the above reasons in the context of organizations,  I see that employees don’t listen to organizations when organizations don’t listen to them. Is this a reasonable hypothesis  ?

On a similar noteI have seen another “Celebrity bias”.  I have seen some tweets from celebrities tweeted  and favorited by hundreds. But the same information published by a lesser known person does not get noticed much.  For example,  if  Seth Godin or Richard Branson say something and if a common man “X” says exactly the same thing, then people tend to believe celebrities more than a common man.

Why do we have this celebrity bias ?

Many people attribute this to  “Halo Effect” .  Some good stuff from the article below…

As you read above, the halo effect can influence how teachers treat students, but it can also impact how students perceive teachers. In one study, researchers found that when an instructor was viewed as warm and friendly, students also rated him as more attractive, appealing, and likeable.

Marketers take advantage of the halo effect to sell products and services. When a celebrity spokesperson endorses a particular item, our positive evaluations of that individual can spread to our perceptions of the product itself.

Job applicants are also likely to feel the impact of the halo effect. If a prospective employer views the applicant as attractive or likeable, they are more likely to also rate the individual as intelligent, competent, and qualified.

So, the next time you trying to make an evaluation of another person, whether it is deciding which political candidate to vote for or which movie to see on a Friday night, consider how your overall impressions of an individual might influence your evaluations of other characteristics. Does your impression of a candidate being a good public speaker lead you to feel that she is also smart, kind, and hard-working? Does thinking that a particular actor is good-looking also lead you to think that he is also a compelling actor?

Categories: Blogs

The Stages of Agile Success

Agile Game Development - Thu, 04/03/2014 - 20:02
Achieving the full benefit of agile requires a long-term commitment to change.  Applying the basic practices, such as answering three questions for 15 minutes a day, is simple, but adopting the mindset of self-organization, continuous improvement and building a culture of engagement, trust and respect is challenging.
The Three Stages of Agile AdoptionOver the past decade, I’ve witnessed common patterns of successful agile adoption and have grouped them across three stages[1] shown below, which I call the apprentice, journeyman and mastery stages.


When speaking about agile, we're talking about the agile values and principles.  How these are embodied in your day-to-day practices depends on your culture and the framework for your process.  Scrum is one such popular framework, Kanban another.  These frameworks are great scripts for starting agile, but over time teams change the practices and even blend them.  In this article, I'll mainly use Scrum terms, but your terms may vary.
ApprenticeTeams that are newly formed and/or are new to agile aren't expected to apply agile practices very well at first.  They need constant coaching as they struggle to figure out who does what and when[2].

Apprentice teams learn how to deliver features at a regular cadence and apply new roles such as Product Owner and ScrumMaster.

I prefer to see apprentice teams follow the practices, such as those of Scrum, “by the book”, because changes at the start of Scrum adoption are usually done to conceal problems Scrum exposes.

Effective Daily Stand-ups
One example of abandoning a practice too early is when teams skip the daily stand-up meeting because they feel an electronic tool is better for reporting task status.  Reporting task status is a part of the stand-up, but it is not the primary purpose and so something is lost.  The daily stand-up is meant to align a cross-discipline team to their daily priorities, revisit their commitment to their sprint goal and recommit their accountability to delivering quality features.  Thinking that it's all about task reporting is a vestige of a task-assignment culture and it takes a while to change this mindset.

Cross-Disciplined Teams
Forming cross-discipline teams that can commit to goals is critical to early adoption.  Departmental or siloed organizations will resist the formation of cross-discipline teams.  Not only do department managers fear losing control, but developers themselves will resist being teamed with those outside their own discipline.  Yet, if cross-discipline teams don't form, then the weight of dependencies and the inability to deliver a demo-able game every iteration, will prevent most of the benefits found with agile.

Well formed cross-discipline teams can take more ownership of their goals, which leads to more effective problem-solving and higher productivity.

Established Roles
Roles, such as Product Owner and ScrumMaster, are meant to balance the need to build the right features in the right order and in the right way.  The roles are separated, because they often come into conflict with one another and need to be balanced for there is a fine boundary between building features faster through improvements to productivity and building features faster by dropping quality.

Realigning existing roles with the new ones take a while to establish and even longer for the teams to understand how they are meant to function.
JourneymanWhen agile teams create a definition of done and start altering their practices to achieve it every iteration, it's a signal that they are entering the Journeyman stage.   The following areas of development maturity are common with Journeyman teams.

Leaner Designs
Through close collaboration, Journeyman teams reduce handoffs of written design documents and concept art.  For example, instead of a dozen storyboards for a level, a concept artist will draw half as many and spend more time working directly with the level artists and designers.  In this way, all disciplines can more effectively collaborate and iterate on more emergent and higher quality levels than a one-way handoff of concept art would allow.

Faster Integrations
As cross-discipline teams iterate more, the inefficiencies of practices such as branch-and-merge and hand-testing everything are replaced by practices such as continuous integration, test servers, unit testing, etc.  These practices allow more iterations on up-to-date assets and code throughout the day.  The ability to iterate more frequently contributes to higher quality.

Better Testing
As mentioned above, faster integration requires improved testing practices, such as test servers.  Additionally, Journeyman teams will increasingly integrate members of QA onto their team.  This will lead to further refinements of the definition of done.

Release Planning
As journeyman teams improve their definition of done, agile estimation techniques can be employed to produce a more reliable forecast about the schedule, cost and scope.
MasteryMastery is a stage occupied by so-called hyper-productive teams.  These teams hold themselves accountable to their results, practices and organization.  For teams to enter this stage, they must have an established level of trust within the organization and be allowed to achieve higher levels of self-organization.

100% Customization
Sometimes, when I visit a team that has been effectively inspecting and adapting agile and Scrum practices for a while, it’s hard to say “they're doing Scrum” anymore.  They completely own their work, and take much pride in it.

Self-organization
The goal of Scrum is to leverage the power of small, self-organizing teams to maximize the value they create.  By giving teams and individuals more freedom to make decisions about their work and providing structure, coaching and mentoring, their work becomes far more focused and meaningful.

Studio culture and structure are often barriers to this “low constraint” form of self-organization.  Fortunately, as more studios emerge that demonstrate the value of this approach, the acceptance and proof of it will continue to grow.

Continuous Improvement
Following a set of prescribed practices isn’t the goal.  The goal is continuous improvement.  Markets and technologies change.  Individuals change.  Processes have to change as well.  There are no "best practices" because the word "best" implies that there are no better.
It's Not Easy, but it's RewardingThe agile state of mind challenges our beliefs and assumption and insists that we continue to challenge them.  It flat-out defies the persistent superstition that we can treat creative people with the same tools that make machinery more productive, that we can add more people or add more hours they work or write bigger planning documents, which will result in more output.  People are far more complex.

It makes us coach, listen, challenge, inspire, care, respect, and collaborate in ways we were never trained to do.  It's a lifetime challenge with no finish line in sight.


[1] These are not unlike the three stages of martial art mastery called “ShuHaRi”
[2] This is not inherent to Scrum teams, all new teams go through a settling phase.  Google “Tuckman’s stages of group development” for more on this.

Categories: Blogs

Announcing Summer of Scrum Toronto 2014 Pre-Registration

Learn more about our Scrum and Agile training sessions on WorldMindware.com

One of our big plans this summer is to have a selection of advanced Scrum and Agile – related training courses.  We are delivering some of them ourselves, but we are also bring in outside experts for others.

Here is the course list at a high level:

- a 1-day “Advanced ScrumMaster” course
- a 1-day “Advanced Product Owner” course
- a 1-day “Managing for Success” course
- a 1-day “Enterprise Agile” course
- a 2-day “Agile Engineering Practices” course
- a 2-day “Agile Coach Training” course

Our schedule for these events will be finalized in the next few weeks.  If you are interested in any of these courses, please pre-register here.  Pre-registration will give you a guaranteed spot and a discount of 10% above and beyond the early-bird registration price.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories: Blogs

Who Solves Which Problems?

Johanna Rothman - Thu, 04/03/2014 - 17:37

Many years ago, I was part of a task force to “standardize” project management at an organization. I suggested we gather some data to see what kinds of projects the client had.

They had short projects, where it was clear what they had to do: 1-3 week projects where 2-4 people could run with the requirements and finish them. They had some of what they called “medium-risk, medium return” projects, where a team or two of people needed anywhere from 3-9 months to work on features that were pretty well defined. But they still needed product managers to keep working with the teams. And, they had the “oh-my-goodness, bet the company” projects and programs. Sometimes, they started with a small team of 2-5 people to do a proof-of-concept for these projects/programs. Then, they staffed those projects or programs with almost everyone. (BTW, this is one of the reasons I wrote Manage It! Your Guide to Modern, Pragmatic Project Management. Because one size approach to each project does not fit all!)

The management team wanted us, the task force, to standardize on one project management approach.

In the face of the data, they relented and agreed it didn’t make sense to standardize.

It made a little sense to have some guidelines for some project governance, although I didn’t buy that. I’ve always preferred deliverable-based milestones and iterative planning. When you do that, when you see project progress in the form of demos and deliverables, you don’t need as much governance.

There are some things that might make sense for a team to standardize on—those are often called team norms. I’m all in favor of team norms. They include what “done” means. I bet you’re in favor of them, too!

But, when someone else tells you what a standard for your work has to be? How does that feel to you?

I don’t mind constraints. Many of us live with schedule constraints. We live with budget constraints. We live with release criteria. In regulated industries, we have a whole set of regulatory constraints. No problem. But how to do the work? I’m in favor of the teams deciding how to do their own work.

That’s the topic of this month’s management myth, Management Myth 28: I Can Standardize How Other People Work.

If you think you should tell other people how to do their work, ask yourself why. What problem are you trying to solve? Is there another way you could solve that problem? What outcome do you desire?

In general, it’s a really good idea for the people who have the problem to solve the problem. As long as they know it’s a problem.

How about you tell the team the outcome you desire, and you let them decide how to do their work?

Categories: Blogs

Agile Inception: Facilitating Innovation Towards Valuable Results

Learn more about our Scrum and Agile training sessions on WorldMindware.com

I recently had the opportunity to help facilitate a client’s “Innovation Challenge”.  Basically, the concept is to get a bunch of people in the room, give them a business challenge and see what they come up with.

I have to say that the format of the workshop that I used is heavily inspired by a training that I did recently called Specification By Example by Gojko Adzic.  I strongly recommend this seminar as well as the book.  Another strong influence is The Inmates are Running the Asylum… by Alan Cooper.  The workshop that I have developed is a sort of hybrid approach, with my own flavour added to the mix.  During an early iteration of the workshop, I didn’t have a title and one of the participants suggested “Agile Inception”.  I think that title works in a space where Agile is established and well understood (e.g. hopefully this blog).  At the same time, this workshop can be run with people who have no prior experience or knowledge of Agile and without even mentioning the word Agile.  This is also good in certain environments where people have developed an Agile allergy.

Anyhow, my goal for the day was to facilitate the building of shared understanding of the challenge itself as well as some ways that the organization could innovate around that challenge through conversation and collaboration.

From the opening remarks it became clear that the product at the centre of the “challenge” was actually in deep crisis:  a shrinking market combined with shrinking market share.  The product had generated approximately $18M in revenue in 2009, compared with $10.4M projected for 2014.  That’s half dead in some people’s books.  The clear Goal was to reverse that trend, starting with at least $11M in 2015.  They needed a powerful jolt of life-giving innovation energy to defibrillate their failing product’s heart.

There were no shortage of ideas about how the product could become better & more profitable.  In fact, there were many, many ideas.  Too many, perhaps.  Once we had established our working agreement for the day, we did a Starfish Retrospective exercise to make visible all of the things that the group wanted to keep doing, start doing, stop doing, do more of and do less of.  Many post-it notes were stuck on the board and we left them there as a reminder of all of the things that people were thinking about that could help us to consider how the product and ways of working on it could be improved.

Then we talked about the Goal.  True innovation—that is, tangible, innovative results with clear benefits—requires a group to focus on a single, clear, SMART (Specific, Measurable, Achievable, Relevant and Time-bound) Goal that everyone in the organization understands and is committed to achieving.  Often times, as was the case with the group on Thursday, taking time to establish shared understanding of the goal can seem redundant and tedious (“we already know what the goal is…”).  However, as we learned through the process of working in small groups to re-articulate understanding of the Goal back to the “customer” (the person paying for everyone to be there) this often requires some further conversation.  Indeed, when the groups presented their understanding of the Goal, there were gaps that needed to be filled by the “customer”.  It took less than 30 minutes to discuss, adapt and confirm the Goal with the customer.  The value of this investment of everyone’s time was tremendous.  The conversation made it clear that shared understanding had already been established to a degree and enabled the group to build on what was already there to make the Goal “SMARTer” in the minds of all of the participants.

A single, transparent business Goal helps us to innovate with focus—to create the right thing.  In addition, we need to develop a single Persona—the ideal, “imaginary” user of the product.  The larger group broke into smaller groups for the subsequent discussions.  The groups worked separately and generated a the details for a few personas.  All 3 personas added value to the conversation.  The Persona of “Lisa” was particularly compelling to the “customer” because she had a clear goal of her own and through innovation, her goal could be aligned with the overall business Goal to create a powerful, “new” product that just might reverse the downward trend.

The next step in innovating with focus in order to generate the best ideas possible: build shared understanding of how Lisa can pursue her goal through her experience of the product in order for the business Goal to be achieved.  In other words, Lisa needs a story.  Her story needs a beginning and an end (for now, until the next story) and all the stages of her journey need to be integrated into a coherent whole.

The last step was for the groups to brainstorm and come up with different ways that the product can deliver Lisa’s story in order to realize the Goal.

I wish I could say more about the really cool ideas that the group came up with, but I am erring on the side of caution when it comes to protecting my client’s competitive advantage.

To wrap up the session, we took a quick, anonymous gauge of how confident the participants felt about achieving the Goal.  Of the 13 participants, two gave their confidence a score of 8/10, six gave a score of 7/10, four scored themselves a 6/10 and one was a 3/10, for an average of 6.5/10.  Not bad, but clearly some work still to go.  So what’s next for them?

Next steps:
  • Get the technical folks involved in the conversation (ideally, they are there from the beginning)
  • Build an increment of their solution
  • Review
  • Continue the conversation and collaboration to build shared understanding 
  • Re-gauge the confidence score
  • Iterate  
  • Repeat 
  • The likelihood of achieving the Goal increases with every iteration

 

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories: Blogs

Using AutoMapper to prevent SELECT N+1 problems

Jimmy Bogard - Thu, 04/03/2014 - 15:13

Back in my post about efficient querying with AutoMapper, LINQ and future queries, one piece I glossed over was how View Models and LINQ projection can prevent SELECT N+1 problems. In the original controller action, I had code like this:

public ActionResult Index(int? id, int? courseID)
{
    var viewModel = new InstructorIndexData();
 
    viewModel.Instructors = db.Instructors
        .Include(i => i.OfficeAssignment)
        .Include(i => i.Courses.Select(c => c.Department))
        .OrderBy(i => i.LastName);
 
    if (id != null)
    {
        ViewBag.InstructorID = id.Value;
        viewModel.Courses = viewModel.Instructors.Where(
            i => i.ID == id.Value).Single().Courses;
    }
 
    if (courseID != null)
    {
        ViewBag.CourseID = courseID.Value;
        viewModel.Enrollments = viewModel.Courses.Where(
            x => x.CourseID == courseID).Single().Enrollments;
    }
 
    return View(viewModel);
}

See that “Include” part? That’s because the view shows information from navigation and collection properties on my Instructor model:

public class Instructor : Person
{
    [DataType(DataType.Date)]
    [DisplayFormat(DataFormatString = "{0:yyyy-MM-dd}", ApplyFormatInEditMode = true)]
    [Display(Name = "Hire Date")]
    public DateTime HireDate { get; set; }

    public virtual ICollection<CourseInstructor> Courses { get; set; }
    public virtual OfficeAssignment OfficeAssignment { get; set; }
}

public abstract class Person
{
    public int ID { get; set; }

    [Required]
    [StringLength(50)]
    [Display(Name = "Last Name")]
    public string LastName { get; set; }
    [Required]
    [StringLength(50, ErrorMessage = "First name cannot be longer than 50 characters.")]
    [Column("FirstName")]
    [Display(Name = "First Name")]
    public string FirstMidName { get; set; }

    [Display(Name = "Full Name")]
    public string FullName
    {
        get
        {
            return LastName + ", " + FirstMidName;
        }
    }
}

If I just use properties on the Instructor/Person table, only one query is needed. However, if my view happens to use other information on different tables, additional queries are needed. If I’m looping through a collection association, I could potentially have a query issued for each loop iteration. Probably not what was expected!

ORMs let us address this by eagerly fetching associations, via JOINs. In EF this can be done via the “Include” method on a LINQ query. In NHibernate, this can be done via Fetch (depending on the query API you use). This is addresses the symptom, but is not a good long-term solution.

Because our domain model exposes all data available, it’s easy to just show extra information on a view without batting an eye. However, unless we keep a database profiler open at all times, it’s not obvious to me as a developer that a given association will result in a new query. This is where AutoMapper’s LINQ projections come into play. First, we have a View Model that contains only the data we wish to show on the screen, and nothing more:

public class InstructorIndexData
{
    public IEnumerable<InstructorModel> Instructors { get; set; }

    public class InstructorModel
    {
        public int ID { get; set; }

        [Display(Name = "Last Name")]
        public string LastName { get; set; }
            
        [Display(Name = "First Name")]
        public string FirstMidName { get; set; }

        [DisplayFormat(DataFormatString = "{0:yyyy-MM-dd}", ApplyFormatInEditMode = true)]
        [Display(Name = "Hire Date")]
        public DateTime HireDate { get; set; }

        public string OfficeAssignmentLocation { get; set; }

        public IEnumerable<InstructorCourseModel> Courses { get; set; } 
    }

    public class InstructorCourseModel
    {
        public int CourseID { get; set; }
        public string Title { get; set; }
    }
}

At this point, if we used AutoMapper’s normal Map method, we could still potentially have SELECT N+1 problems. Instead, we’ll use the LINQ projection capabilities of AutoMapper :

var viewModel = new InstructorIndexData();
 
viewModel.Instructors = db.Instructors
    .OrderBy(i => i.LastName)
    .Project().To<InstructorIndexData.InstructorModel>()
;
 

Which results in exactly one query to fetch all Instructor information, using LEFT JOINs to pull in various associations. So how does this work? The LINQ projection is quite simple – it merely looks at the destination type to build out the Select portion of a query. Here’s the equivalent LINQ query:

from i in db.Instructors
orderby i.LastName
select new InstructorIndexData.InstructorModel
{
    ID = i.ID,
    FirstMidName = i.FirstMidName,
    LastName = i.LastName,
    HireDate = i.HireDate,
    OfficeAssignmentLocation = i.OfficeAssignment.Location,
    Courses = i.Courses.Select(c => new InstructorIndexData.InstructorCourseModel
    {
        CourseID = c.CourseID,
        Title = c.Title
    }).ToList()
};

Since Entity Framework recognizes our SELECT projection and can automatically build the JOINs based on the data we include, we don’t have to do anything to Include any navigation or collection properties in our SQL query – they’re automatically included!

With AutoMapper’s LINQ projection capabilities, we eliminate any possibility of lazy loading or SELECT N+1 problems in the future. That, I think, is awesome.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

Querying An In-Memory Array Of JavaScript Objects In NodeJS

Derick Bailey - new ThoughtStream - Thu, 04/03/2014 - 13:00

I found myself wanting to query an array of in-memory objects in my NodeJS app. I know there are a ton of options out there… including the built-in filter method on arrays, underscore or lodash where methods, and more. But I really wanted something that worked like MongoDB queries. 

What I Want To Do

Given this data structure:

I wanted to write a query that looked something like this:

sift.js: How I Got What I Wanted

What I found (thanks to Joe Gornick) is sift.jsa MongoDB inspired query library for JavaScript arrays.

It’s pretty slick. It let’s me write and execute the above query, running it against my array of objects:

This returns the second object, as I expected.

Lots Of Options

From the documentation, it looks like it should work in browsers as well as nodejs environments. Of course, this all makes me wonder if MongoDB could create a portable version of their query library to use in NodeJS… but I’m liking sift so far. It does what I want, and seems small / simple enough.

I’m sure there are plenty of ways to achieve close-to this syntax with other libraries like underscore / lodash, or other JSON / JS query libraries, too. I picked sift because I like that it models after MongoDB queries. I’m already familiar with that syntax, and I’ll be able to take advantage of it as I need more complex queries.

     Related Stories 
Categories: Blogs

Peter Drucker on Knowledge Worker Productivity

Agile & Business - Joseph Little - Thu, 04/03/2014 - 05:31

In the Winter of 1999, Peter Drucker had published an article on Knowledge Worker Productivity: The biggest challenge.  Here is access to the article.

Here is the second sentence: “The most important contribution management needs to make in the 21st century is similarly to increase the productivity of knowledge work and knowledge workers.”

Here is a quote from some key ideas in the article:

Six major factors determine knowledge-worker productivity.
▪ Knowledge-worker productivity demands that we ask the question: “What is the task?”

▪ It demands that we impose the responsibility for their productivity on the individual knowledge workers themselves. Knowledge Workers have to manage themselves. They have to have autonomy.
▪ Continuing innovation has to be part of the work, the task and the responsibility of knowledge workers.
▪ Knowledge work requires continuous learning on the part of the knowledge worker, but equally continuous teaching on the part of the knowledge worker.
▪ Productivity of the knowledge worker is not—at least not primarily—a matter of the quantity of output. Quality is at least as important.
▪ Finally, knowledge-worker productivity requires that the knowledge worker is both seen and treated as an “asset” rather than a ”cost.” It requires that knowledge workers want to work for the organization in preference to all other opportunities.

Very interesting ideas.

twittergoogle_plusredditlinkedinmail
twitterlinkedinrss
Categories: Blogs

Setting Expectations

George Dinwiddie’s blog - Thu, 04/03/2014 - 03:50

Karl Scotland wrote an excellent blog post on Estimates as Sensors. In it, he extols the use of estimates to “sense capability and create feedback for yourself.” This is similar to my point in Estimation as Hypothesis.

At the end of this post, it now says “I don’t recommend using them to make promises and give guarantees to others.” Originally, this said something like “I don’t recommend using them to make promises and setting expectations of others.” I asked him what he did use for setting expectations. He had two responses. “I’d say expectations are set from understanding our capability, refined through sensing, and with a confidence range.” and changing the post to reflect his original intent.

There’s more to this business of setting expectations.

First of all, when we uses sensing estimates to understand our capability, we’re setting our own expectations. We can be pretty ignorant of those capabilities if we’re not paying attention. And, as software developers, we’re usually paying attention to myriad other details rather than our own capability. I know I do.

Years ago, I had a project lead who asked me to estimate how long it would take to fix a reported bug in some code written by a colleague who’d since moved to a different project. I looked at the bug report and made a list of the changes I would have to make. Then I estimated how long it would take to edit, compile, and verify each of those changes. I handed this annotated list to the project lead. He took one look at it and said, “You can’t do any task in 10 minutes. It will take you longer than that to checkout the code, find the place to change, and check it in again. Never estimate a programming task at under 30 minutes.” That’s when I realized that I was only estimating part of the required work, the programming part on which I was focused, not the necessary parts that enabled the programming.

I’m pretty terrible at tracking my own capacity as an individual. Not only do I tend toward a narrow focus that excludes that, but I forget to track interruptions. An interruption already gives me two things to think about at once, but tracking it would be a third. That’s a lot for one brain. I do better when I’m part of a team. The nature of team work allows me opportunities to pop up to a larger viewpoint more easily. And within a team that’s worthy of the name, it’s easy to be honest about both the capability and the uncertainty concerning it.

Even as we gain a better understanding of our own capacity, how do we set appropriate expectations for others? This is the crux of many estimation conundrums. Most developers are used to low trust relationships with those asking for estimates. They’ve been burned in the past with estimates being treated as guarantees, with estimates being treated as initial positions for negotiations, with estimates being accepted without the conditions assumed for the estimates. Who hasn’t estimated how long some task would take and then be given another task to do in the same time?

If we know how our estimates are going to be treated, we can apply “fudge factors” or “Kentucky windage” to compensate. If we know our manager is going to cut our estimate in half, we may double the number we offer. Knowing that our estimate is going to be treated as a commitment, we may pad it for contingencies. Knowing that we’re going to be subjected to interruptions, we may extend it based on interruptions in the past. How much we pad depends on whether our estimate is expected to be at the 100%, 99%, 90% 80%, or 50% confidence level.

In fact, the padding tends to go up radically the higher the expectation for the estimate. These two measurements are also related to the consequences for missing it. When someone expects an estimate at the 100% confidence level, they’re outside the realm of the natural world. There is always the possibility of something completely unpredictable, a “black swan” in Taleb’s terminology. With that unreasonable level of expectation, people often couple it with a sense that if something does go wrong, someone should be punished. There’s no allowance for things outside of someone’s control.

There is always some things we don’t know, and some of those are things we don’t know we don’t know. A friend once devised Hughes Law: “On any boat maintenance project, there will be at least three unforeseen complications, at least one of which will follow this law.” He recommended taking your estimated time for the work, tripling the number, and incrementing the unit of time measurement. That two day job becomes 6 weeks. When we have an extreme level of uncertainty, then giving any number can make us nervous.

What if we were able to set expectations beyond a simple number? What if we could say what we know and what we don’t know? What if we could give our best estimate now, and give a better one next week when we know more? Would that help?

The thing is, these questions are not about the estimates. These questions are about the relationship between the person estimating and the person using the estimate. How can we improve that relationship?

Categories: Blogs

It’s MAD to Put All Work Through Discovery

Constant Change - Aaron Sanders - Wed, 04/02/2014 - 16:15

I was sitting with a team when their manager came in and asked, “Hey. Are you guys finished with this feature?” The Scrum Master responded, “We haven’t even had time to even begin the discovery on it yet.” The manager looked surprised and said, “Oh, OK. Would you let me know when I can see […]

The post It’s MAD to Put All Work Through Discovery appeared first on Aaron Sanders.

Categories: Blogs