Loading...

Follow Lean Agile Training on Feedspot

Continue with Google
Continue with Facebook
or

Valid

Question: What should I do if I cannot get a real Team?

Answer:

First, let’s assume you are doing something important.  That it is the next most important thing to do at your company (eg, a release).  If so, you would do best to get a real Team.  And Scrum will have a bigger positive impact with a real Team.  And you will be more successful.  Pretty much guaranteed. So that, any costs of getting a real team will be well-repaid.

There are many senses in which one cannot get a full real Team.

Examples of a not “real team”:
– part time team
– not fully motivated
– not the right skill set
– not collocated (and in this case you know that is not good — for example, in your case you know that will seriously diminish communication)
– too many distractions
– they just won’t work with each other

So, what can you do?

The short answer: do the best you can.

The longer version…

Sometimes you know the thing to do is stop. You can tell you will not succeed, and the best thing to do is stop.  It sometimes happens that when you recommend stopping, then managers will take action and fix some things.

Sometimes you see that things are compromised, but you are not sure how big the impact will be.  You might succeed or your might not.

In that case, I think I recommend that you try to play it, as best you can immediately, as a Scrum team.  As close to a real Scrum team as you can get. By definition, it will be a half-baked Scrum.  But something Scrum-like.

Scrum will tell you how much this hurts you. You can see, Sprint by Sprint, whether this maybe is working ok (not great but ok) or whether it is quite bad.

Again, it is not SCrum per se that is bad, but rather Scrum allows you to see that the Team (or the Team situation that you have) is “less than optimal”.

The idea is that (a) it might not be that bad. It might be ok, even pretty ok, as they say.  Or (b), now that you know it is bad and everyone can see it, you maybe can do something about the problem. Often, with the clearer evidence that Scrum gives, some managers will now take action.

Sometimes you will see quickly that things will move, the team will get something, not a lot but something done, Sprint by Sprint, but not very fast. Sometimes people are ok with “slower than hoped for”…and sometimes they will make the situation better.

Could I recommend another approach than Scrum? Should you try waterfall, for example?

Honestly, I cannot in good conscience recommend waterfall. As suggested, you might have to do a half-baked version of agile-scrum. Do that or give up. In my opinion, even if you are not well-trained or well-experienced, your half-baked version of agile-scrum will help you succeed better than using waterfall.

OK, I can imagine one situation (unlikely for most of you).  Imagine that you have a small group, who kind of have the skill set.  Imagine they do not want to do Scrum. Imagine you know that fairly well, and they, together, have done a “successful” waterfall project.  Imagine that you feel confident that the “Google approach” (see the Mark Striebeck article here) will not work.  Well, doing another waterfall project is maybe not a terrible option.   Why then am I reluctant?  Because I know, from much experience, that the situation will have change, and that the Team could (if they would try it) almost surely do better with Scrum, even half-baked Scrum.

I accept that a small percentage of people do not like to be in a team (although most introverts like it once they get used to their team).  And Scrum is a team sport and waterfall, basically, is not.  So, possibly (a very unlikely chance, but possible) you are in that situation.

***

There are lots of scenarios.  You may have been through this situation.  If so, please share you experience.  Or ask your questions.

The post What should I do if I cannot get a real Team? appeared first on Lean Agile Training.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Question: How can I help a distributed Team be more productive?

Answer:

First, one of the most important things about a small team of knowledge workers is communication.

Why is communication so important?   There are many ways to answer this question.  In creating knowledge together, the team is always learning. As they get to know each other, and what each other knows, they learn a short-hand for talking. They don’t waste time reiterating what is already known, but focus on the essential knowledge for today, that moves the product forward.  Well, that’s a short way of saying it.

With a distributed team (a team that is not fully collocated) communication is diminished. How much it is reduced varies a lot.

Here are some recommendations.

#1 Evaluate whether a distributed team really will help.

Usually a distributed team is cheaper (or some members are cheaper). Always the communication is reduced. That means more hours are needed (both for the inexpensive people and for the expensive people).  That also almost always means that the product will be somewhat delayed.

Please evaluate, ahead of time, the benefits and the costs.  And then evaluate afterward how accurate your projections were.

I am not saying never do distributed.  But I do find that many companies look at the benefits (reduced cost) and do NOT look at the overall situation. I think many times distributed is not really helpful.

#2 Distribute into 2 evenly sized teamlets.

For example, have one teamlet of 4 in New York City and another teamlet of 4 in Bangalore.  Each teamlet is collocated.

Because they are equal in size they will be seen as equal in importance.  Neither team will be tempted to ignore the other half of the Team.  Both “sides” need to keep each other informed.

This recommendation includes a local team room for each teamlet.  And making the team rooms look similar, so that there is no sense of divide between the teams.  Each team spends roughly 4+ hours in its own team room.

#3 Collocate the Team initially.

You must collocate the Team initially.  There is no choice.  They must get to know each other as real people. It is so important that they get to know each other in person, and spend some time eating together and talking about non-work subjects.  Probably the best way is to spend most of some days working on getting the work started.

There is a good argument that you get them collocated for 6 sprints, so how high you can get the velocity, and then ask them to maintain that high velocity while distributed.

#4 Get together again later.

It is important to re-collocate.  For example, to have one team member in NYC go to Bangalore for 2 weeks.  Get to know them as people again.

This helps with communication. One appreciates the other person more. One is more patient with the inevitable problems of communication.

#5 Improve the technology around communication.

This might be a better polycomm. It might be improving the “virtual presence” technology so that the video conferencing works even better.  It might be adding video cameras for each person.

#6 Train the people to communicate better via the technology

I find that many companies have good technology, but they often do not train the people (enough) in how to use it.  So that the full benefits are not realized.  You cannot assume people have studied communication and how it works best, nor have they studied the new tool and mastered it.  One or two might, but it is very typical that they do not.

#7 Overlapping hours

Identify when the two teamlets overlap in terms of work day.

When the teams overlap, keep the Polycomm open for those hours.  That way they can instantly communicate with each other, eg, by tapping on the Polycomm.

#8 A common Scrum Tool

If you are distributed, you must agree on a Scrum tool (or agile tool) to use.

There are many of these.  There is not a clear winner.  Probably you decide this way: “Anyone here know a specific Scrum Tool?”  “I know X.”  “Well, then X it is.”  And this is likely the correct decision because that person can help you use it better.

One aspect of this is visual display of the Scrum Board and similar things.  This requires, usually, a big TV monitor for both teamlets.  Well worth it.

#9 A common tool set

Many aspects to this, although most of this seems obvious.

One aspect is a common place for documents.  This might be a wiki or Sharepoint or who knows what (obviously, I am not speaking of the codebase itself now).

And the training and communication to organize the documents well, so that they then are used well by the Team (and others).

#10 Texting

There are now many tools.  Slack is one.

Agree on a tool.  And take the time to train members of the team to use it well.  And train them when NOT to use it.

These texting tools do NOT obviate phone and video conferencing.  We still need those a lot.

#11 An Impediment List for being distributed.

I recommend, at least for a while, that the Team keep a special impediment list just being distributed.

And maybe a list of fixed or mitigated impediments.  “What have we done so far…eam

Prioritize the list and actively attack the top impediment.  Not being collocated is hard.

#12 Language and accents and understanding

There are many reasons that people do not understand each other.  One is that they always speak a dialect of their “own” language.  The local Charlotte version of “Southern English”, as one example.

Next, everyone speaks in an accent…at least to others.  Accents can be very charming and interesting.  But our main point now is that often the accent gets in the way of communication.  I mean not only the accent, but the rhythm of speaking and where emphasis is put (eg, which syllable gets the emphasis).

This can start to be a touchy or sensitive subject. But still it is important, because it can notably reduce the communication between members of a team.

You may need to bring in an expert or a coach to help with this. First, to help team members speak up and explain their concerns.  And then to help them overcome the problem.

#13 Culture

We can have cultural difference between people within one mile of St. Paul’s cathedral.  (This is tease about some comments in the movie My Fair Lady. Perhaps most of the readers do not recognize it, which is fine. And kind of an example of what I mean.)

So, we always these days have cultural differences within the team.  I think in every team (at least that I can remember).  I suppose in theory it is possible not to have almost any cultural differences, but I do not see that often nowadays.

We all deal in stereotypes and cliches.  Our brains force us to simplify.  We must generalize about people and things and situations.  Everyone does this.

I am NOT recommending being mean to people.  I am just saying that people inevitably over-simplify life. Life requires that of our brains.

Inevitably, in real life, one notices that in many instances the stereotypes and cliches are not accurate at all.  Cliches that Canadians have about Americans or Americans have about Canadians are not, at least in specific cases, always true.  Even though the cliche probably is in general true (a simple example: “The typical city in Canada gets more snow than the typical city in the US.”….as a generality probably true).

We also know from experience that expressions of some cliches or certain words can be seen as insulting or hurtful, even though the person saying it may say it very innocently or without knowing.  And we have certain social rules about this… or each culture does.

As one example where difficulties might arise:  How to say “no” to another person one does not know well?  This varies from culture to culture.  I think, in almost all cultures, to answer a question with a blunt and loud “No” is considered impolite.  But exactly how to answer, in a polite way, varies a lot culture to culture.

This whole culture area is quite complex. One might like to avoid it.  But we cannot.

It is, I think, natural for a member of a culture to feel, deep down, that his or her own culture is the best.  And probably this is mostly a good thing.

Inevitably, case by case, the people in a team must decide which cultural norm to use now, or to come up with a new “cultural norm” that the team can use.

Net, net: You must discuss culture.

I recommend taking some time to appreciate and learn about each culture in the team.  Most people can find other things in a “foreign” culture that they like.  The food, the sports, the way of dressing, the arts, many many things. Almost always there are things that can easily be appreciated.  And say so.

And every culture is complex. Speaking for myself (partly), I find North Carolina culture to be very complex.  I have known it almost my whole life, and yet there is so much about it I still do not know, or do not fully know.

Does your team have cultural issues?  Yes!  In fact, that is has some is virtually inevitable.  And this can happen whether or not the team is distributed.  And the cultural issues lead to lower productivity and happiness.  Usually do to less or less effective communication.

Being distributed just makes the cultural differences typically bigger (as they usually say) and harder to communicate about.

Could your team need a “culture coach”?  Yes.

This subject can easily become quite sensitive and therefore hard to talk about.  Sometimes you have someone in the team or near the team who can help the team discuss these issues. For example, sometimes there is a Canadian who has lived in the US for a long time, who can explain Americans to Canadians and, equally, Canadians to Americans.  (“Two people separated by a common language” comes to mind.)

But sometimes no such person is there.  And one needs to bring in an outside “culture coach” (the role may have different names).  This person can help each side of the team express their concerns or “the problem” or the mis-understanding.  And then, we hope, overcome it so that then the team communicates better. Or collaborates better.

This is typically the goal: We need to overcome cultural difference so that we can communicate or collaborate better.

And…it also needs to be recognized that cultural difference are also advantages. Often the team “sees” more and learns faster due to the differences within the people in the team.  So, also respect the advantages that cultural differences can bring to the team.

***

Comments and suggestions about this post are welcome.

The post What do I do with a Distributed Team? appeared first on Lean Agile Training.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Question: What should I do if I cannot get a real Team?

Answer:

First, let’s assume you are doing something important.  That it is the next most important thing to do at your company (eg, a release).  If so, you would do best to get a real Team.  And Scrum will have a bigger positive impact with a real Team.  And you will be more successful.  Pretty much guaranteed. So that, any costs of getting a real team will be well-repaid.

There are many senses in which one cannot get a full real Team.

Examples of a not “real team”:
– part time team
– not fully motivated
– not the right skill set
– not collocated (and in this case you know that is not good — for example, in your case you know that will seriously diminish communication)
– too many distractions
– they just won’t work with each other

So, what can you do?

The short answer: do the best you can.

The longer version…

Sometimes you know the thing to do is stop. You can tell you will not succeed, and the best thing to do is stop.  It sometimes happens that when you recommend stopping, then managers will take action and fix some things.

Sometimes you see that things are compromised, but you are not sure how big the impact will be.  You might succeed or your might not.

In that case, I think I recommend that you try to play it, as best you can immediately, as a Scrum team.  As close to a real Scrum team as you can get. By definition, it will be a half-baked Scrum.  But something Scrum-like.

Scrum will tell you how much this hurts you. You can see, Sprint by Sprint, whether this maybe is working ok (not great but ok) or whether it is quite bad.

Again, it is not SCrum per se that is bad, but rather Scrum allows you to see that the Team (or the Team situation that you have) is “less than optimal”.

The idea is that (a) it might not be that bad. It might be ok, even pretty ok, as they say.  Or (b), now that you know it is bad and everyone can see it, you maybe can do something about the problem. Often, with the clearer evidence that Scrum gives, some managers will now take action.

Sometimes you will see quickly that things will move, the team will get something, not a lot but something done, Sprint by Sprint, but not very fast. Sometimes people are ok with “slower than hoped for”…and sometimes they will make the situation better.

Could I recommend another approach than Scrum? Should you try waterfall, for example?

Honestly, I cannot in good conscience recommend waterfall. As suggested, you might have to do a half-baked version of agile-scrum. Do that or give up. In my opinion, even if you are not well-trained or well-experienced, your half-baked version of agile-scrum will help you succeed better than using waterfall.

OK, I can imagine one situation (unlikely for most of you).  Imagine that you have a small group, who kind of have the skill set.  Imagine they do not want to do Scrum. Imagine you know that fairly well, and they, together, have done a “successful” waterfall project.  Imagine that you feel confident that the “Google approach” (see the Mark Striebeck article here) will not work.  Well, doing another waterfall project is maybe not a terrible option.   Why then am I reluctant?  Because I know, from much experience, that the situation will have change, and that the Team could (if they would try it) almost surely do better with Scrum, even half-baked Scrum.

I accept that a small percentage of people do not like to be in a team (although most introverts like it once they get used to their team).  And Scrum is a team sport and waterfall, basically, is not.  So, possibly (a very unlikely chance, but possible) you are in that situation.

***

There are lots of scenarios.  You may have been through this situation.  If so, please share you experience.  Or ask your questions.

The post What should I do if I cannot get a real Team? appeared first on Lean Agile Training.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

One of the key things about the ScrumMaster is that he/she has no power.  No authority.

Well, I remember a line from somewhere (which I cannot find now) that “the ScrumMaster has no authority”… and I understood that meant that the ScrumMaster did have the authority to help define what Scrum is supposed to be, but not the power to make people “do Scrum.”

It is important to remember that in most companies (in my opinion), the SM is viewed as the “new” project manager.  So, particularly at first, the SM must act contrary to how the former PMs acted, so that people no longer think that way.

One idea is that a servant leader is not really a servant leader if he/she leads using power or position.

Equally, the SM is not a quiet mouse.  The SM has a right to speak up. But not as a boss or someone with power, but rather as someone with wisdom.

Some of the descriptions I read talk about the ScrumMaster as a slightly different project manager.  NO!

The SM helps, and that help is VERY important.  But the others in the team do the real work.  In simplistic terms, the PO envisions the product and the Doers (Implementers) build it.  And the SM gets impediments (of any type) out of the way as fast as possible.

So, for example, the SM does not set the goal or goals. Although a ScrumMaster might make sure a goal is set and that it is clear to the whole Team.

For doing the work, the SM is not a key locus of communication.  That is, information about the product does not need to go through the SM.  Although the SM might observe whether communication of all sorts is working well (typically, there are key areas for improvement…this is VERY common).  It is also important that the Team is communicating impediments and related information to the SM (and vice versa).

The SM does not reward the Team, eg, with applause or recognition.  The SM might get someone else to say “wow” or “thank you”.  But the SM is not the PO or the customer.  Still, getting someone to give sufficient recognition might be a key impediment to solve today.

The Team does not win the game for the SM.  They win the game for the customers or maybe for the PO or the business side.  But not for the SM.  At least, that is not something the SM would say.  (One can imagine the Team maybe feeling that way, but the SM should not put it that way.)  The normal case, I think, is that they want to win to prove something to themselves.  And to give to the customers.  That would be a better motivation.

One of the key things: The SM is always a servant and s/he does not make herself or himself the center of attention.  He is “only” the servant.

This is notably less self-important than most project managers were seen as.  In my experience.

***

Your comments are welcome.

The post ScrumMaster: No Power appeared first on Lean Agile Training.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

First, can knowledge decay?  Yes.

Is it possible that you are mis-remembering knowledge, and you think you are doing Scrum right, but in fact you are doing it incorrectly?  As most of you know, this is very possible.

Is there a magic pill to make sure everyone’s knowledge is perfect and everyone’s intention is perfect?  Would that there were, but NO!

***

So, Scrum Alliance has come up with some practical things.  They are attempts to deal with these problems.

To be honest, this is a bit bureaucratic, but have some sympathy.  It is a hard problem, and the proposed solution could have been worse.

If you dislike their proposals, please tell me, and please do propose an alternative.

Valid Certification

Scrum Alliance wants everyone to have an up-to-date, valid certification.

And your certification expires after two years.  (Exactly how that works….lots of detailed questions.  It is shown on your Scrum Alliance profile.)

Get SEUs to renew

To renew your certification, you must obtain SEUs.  Scrum Educational Units.

Basically, they try to represent the idea that you have new learning in that (2 year) period.

And the idea is that the new learning “justifies” letting you continue with your certification.

Lots and lots of industries do this kind of thing.  Lawyers, doctors, etc, etc.

Is it perfect?  No.  Does it help?  Probably on average YES.  Well, make it help for you.

Here is a page that talks about renewing:

https://www.scrumalliance.org/get-certified/renewing-certifications

What are SEUs?

Here is a page that explains the different types of SEUs and gives you ideas of how you can earn SEUs.

https://www.scrumalliance.org/get-certified/scrum-education-units

Coming to one of our courses is one of them.

How many SEUs do I need?

It turns out this might be complex.  Depends on several factors.

See this calculator.

https://certification.scrumalliance.org/renewal_requirements

And see this video:

We will try to keep up with this.  We do have more to say about how we can help.

You can email: support@scrumalliance.org.  Or talk to us.

More soon.

The post Renewing your certification / Furthering your education / Renewing appeared first on Lean Agile Training.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

We have just done a short (5 minute) video on our Scaling Workshop.

We think this 1-day workshop is the best way to improve, iteratively and incrementally, toward better scaling.

We hope you find it interesting and want to talk more.

Enjoy!

Our Scaling Workshop - Explanation - YouTube

The post Our Scaling Workshop – Explanation appeared first on Lean Agile Training.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

We just prepared a video to explain our Agile Release Planning workshop.

The Attendees often say it is “essential”.  Or highly recommended.

So, here’s a 5 minute video that explains it a bit more.

Hope to see you in the workshop!  Bring your team!

Enjoy!

Agile Release Planning Workshop - Explanation - YouTube

The post Our Agile Release Planning Workshop appeared first on Lean Agile Training.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Sometimes I am asked, why do you dwell on the basics of Scrum in your CSM class.

A couple of obvious answers, although not the most important:

  • there are beginners in most classes
  • Scrum Alliance expects me to cover the basics
  • while the students read the Scrum Guide (often) before the class, they do not understand it or remember it well.  Often.
  • the CSM course is the main course for most people where we DO cover the basics. (There are other courses.)

Is there more to say about Scrum (or even love) than can be covered in two days?  ABSOLUTELY!  To cover Agile-Scrum even in summary to me would take 5 days.  But that is too long.  Most adults can learn 15 times more stuff in 2 days than they could ever take action on in the next 6 months.  So 2 days (well, I think 3 days) is enough for the FIRST course.

Here are two more fundamental reasons:

  • there are now “out there” a thousand WRONG examples of how to do agile and Scrum
  • real success almost always is based on doing very basic things very well
The Bad Examples

There are indeed a few (percentage wise) examples of … we have different names for it:

  • pretty good scrum
  • Aggressive Scrum (Jeff Sutherland’s preferred term)
  • Successful Scrum
  • Hyper-productive Scrum
  • Scrum where the participants are truly deeply madly happy with it (Cf Alan Rickman…a great actor, if you ask me…apologies to that movie)

There are other names too.

And I tease a bit about how happy the team is (I am from New England to a large degree, and we like to keep a stiff upper lip….too much happiness definitely feels a bit suspicuous).  But, really, a team that is truly happy is usually delivering wonderful stuff (over time) to their customers. This is indeed a wonderful thing.

BUT…

Honestly, the are lots more examples of…we’ll be kind and call it…”not very good Scrum yet”.

Apparently, out in the world, mis–understanding and stupidity are rampant. And there are so many reasons why.

So, most of you need to be armed against all the stupid ideas (not saying the people are really stupid, but the ideas are, once you understand enough)…all the stupid ideas about agile and scrum.

As one example, most any agile trainer can easily put together a list of 10 favorite myths about agile.

So, we go through the basics carefully to prepare you to defend the team (and others) from the rampant stupidity.

Blocking and Tackling

When I was a kid I grew up watching football with my family (especially my father and brother).  The saying was: the difference is usually in the basics of blocking and tackling.  Very basic stuff in football.

And I see that that this true in agile and scrum as well.

So, I cover the basics carefully (really, too short given the time constraints) so that you have a better chance for success.

***

Maybe one thing more worth saying now.  If they are not doing the basics, at least one of two reasons usually are true.  No one taught them the basics (correctly) [alternate version: they did not listen at the time it was taught.  Well enough.]  Or, they do not understand WHY the basics, or a particular thing, is important or useful or necessary.  The first one is kind of obvious, although in reallife hard to spot sometimes if you do not watch very carefully.  The second one is even harder, usually. And they are smart enough to give a seemingly plausible excuse why they are not doing some basic thing now.

It takes a strong-minded, observant ScrumMaster to help them become the great time they can be.  Many a talented football player never graet because they did not want to put in the time practicing the basics.  (I can hear a thousand football and basketball coaches saying “Amen brother!” right now.)

The post Why dwell on the basics of Scrum? appeared first on Lean Agile Training.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

The following email lacks some context, but I wanted to post it anyway.  This is what I usually say (enact) at the end of the Agile Release Planning segment or workshop.  Hope it helps you.  This was said in a recent email to a class, as you’ll see.

***

Hi all,

There was something important that I did not explain. About Agile Release Planning.

As with all the important things in life, it is what it appears to be, and at the same time it very different than what it appears to be.

What do I mean?

Well, obviously, we are doing planning, or so we think. And the output is a kind of plan. The product backlog broken into releases and sprints.

How good is that plan in the first day? Crappy. It has to be, because we are missing so many puzzle pieces. Roughly half.

So, what was the real purpose of that day?

I use body language to help you remember, because this is important.

First, I raise my arms and do kind of a circle above my head. That represents a big animal. An elephant (you will recall). And I say “they know all see the same elephant”.

Second, I move my hands out and forward from my stomach. That represents (not my best one) motivation. They are all more motivated. They all feel like “this is my baby, I helped create this”. And all the engagement, commitment, buy-in, involvement that implies.

Third, at my waist I move my hands in circles. Some people laugh and say “wax on, wax off”. Then I say “we are sharing….” Pause. “Sharing what kind of knowledge?” Takeuchi and Nonaka talk about 2 types of knowledge: tacit and explicit. (Read about that.) “So, we shared the … most important one….the tacit knowledge. And now we all know what we all know.”

“Now the people are waiting, willing, and wanting to do the project.” Usually at this time I ask Grant: “What is more important to project success? (pause) The people or the plan?” Grant thinks for only a moment and says “the people”. “So, you see, we accomplished something far more important than the plan. We got the people ready to do it.”

And this is the only way I know to accomplish that goal. There are other ways, maybe almost as good, to develop a plan. The initial plan. This is the only way, certainly the best I have ever found, to get the people ready. And we do team building as well, but people usually hate teambuilding exercises, so never tell them we are doing that. Just let it happen.

I hope those comments are helpful. Sorry you missed the body language.

Thanks!
Joe

***

The post The key purpose of Agile Release Planning appeared first on Lean Agile Training.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

To have a decent Agile-Scrum Team, here are my conditions:

  • An important set of work
  • An ability to define that work well enough (clearer requirements)
  • A team that wants to do that work — an inspired team would be great
  • A team that is willing to try Scrum
  • The courage to face the truth
  • Someone who knows Scrum well enough to explain it accurately (not a beginning SM)
  • A 100% allocated and stable Team

Here are some more conditions:

  1. A team that is not dysfunctional
  2. A team that is capable enough (right skill sets)
  3. A willingness to identify enough impediments
  4. A willingness by the team and the organization to change things to fix impediments
  5. The thoughtfulness to add to Scrum usefully
  6. The ability to get decent feedback each Sprint

Can you be successful without these?  I suppose so, depending on who you are competing against.

But aren’t these reasonable conditions that management should provide so that a Team can be successful?

The post Necessary Conditions appeared first on Lean Agile Training.

Read Full Article

Read for later

Articles marked as Favorite are saved for later viewing.
close
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview