Lean is Lean – no matter what value stream you support. It is all about engaging everybody, every day in solving problems, adding more value, utilizing fewer resources, and ultimately achieving the organization’s purpose through helping customers achieve their own purpose. Whether it is on the factory floor or during a sales call, we all have to improve our work while changing the way we think and act.
Tuesday, March 24, 2015
Saturday, March 21, 2015
Innovation is a particularly sticky problem because it so often remains undefined. That’s why efforts tend to be fraught with buzzwords and rarely lead anywhere. Well, There is more to innovation than just product innovation. There are actually more than just few types of innovation and Different types of innovations address different types of problems.
Innovation is top of mind for many companies today. It is tagged as a core driver for creating competitive advantage and growth. Successful companies don’t just innovate - they innovate better. Innovation processes, practices and tools certainly play important roles , Other factors such as access to funds, risk tolerance and management support also create conditions favorable to innovation, but highly innovative outcomes seem to have something more – the Innovative environments and culture that leads to the innovation results.
Thursday, March 19, 2015
How does it look like when a Scrum team does not understand the techniques, or even the value of splitting large chunks of work into smaller, working software chunks? What is the risk in not dealing with this issue fast enough? What can we do about it besides simply teaching the techniques? and why?
100% of the times when we are engaged in an Agile implementation inside an organization, we hear developers say -- and mostly this comes from team leaders, that it's impossible to divide big chunks of work into smaller ones (it may be dealing with large user stories or the technical aspect of splitting user stories to tasks, or other variations of the same slogan: "we can’t divide it to smaller portion”). Not only that, it is often assumed that large technical assignments cannot be divided into smaller ones. It’s a ”one hundred percent thing” - At the early stages of the implementation the thought that this is actually impossible is very common.
The absence of this skill, the mindset or understanding of the value in splitting large chunks of work into smaller working chunks is one of the painful issues that encourage and build resistance inside Scrum teams. We need to deal with it. Because resistance, if left untreated, can get out of hand.
It come in a lot of shapes, colors and forms, For example:
"The sprint should be one month since we will not be able to see anything working sooner, it’s plain impossible"
"Splitting to small chunks may work for existing code, but not for new features"
"Splitting to small chunks may work for new features but not for existing code"
"It is irrelevant when it comes to bugs"
"You can't do it for a research assignment"
"Our server side is more complicated than the GUI side, which is why they can do it. We just can't even if we would want to"
"Our GUI side is more complicated than the server side, which is why they can do it. We just can't even if we want to"
"UX is different. You can never do it"
"I have nothing to say on the daily anyhow – it's too big a stop"
"Experienced developers can and should have a backlog of large issues instead of wasting our time with small user stories."
"Its too much testing anyway, it’s a waste of time."
"Technically it cannot be split… whatever the merits, the business side will not be interested anyway."
"The Sprint was delayed because we can't split these stories, it's not doable"
"There is nothing to demo this sprint"
"Of course one could always split them into several so called "technical stories", but they are, with the exception of refactoring spikes, a big no-no in Agile, aren't they? "
"In fact, the last 6 months, I've been working on a project where the entire point is for customers to notice no difference (platform migration)". http://pm.stackexchange.com/questions/2316/how-to-handle-user-stories-that-cannot-be-split-and-do-not-fit-even-a-30-days-lo)
It may even look like an active, strong emotional resistance toward the coach or toward technical managers in the organization. I found that team leaders who possess less technical skills, or who are less confident about their skills, or are less experienced as managers, often provided very dramatic or deterministic examples of these types of statements, to the point of ridiculousness. This behavior itself is very dangerous to an implementation and to the team mindset we wish to acquire.
I think the problem lies with these team leaders’ inability to immediately understand how to divide big chunks of work. This threatens their core professional image as software developers and poses a real threat to their confidence regarding their abilities as skilled developers. The resistance can be very strong, and as a coach you know that you have to face these issues and you need to get those developers from the theory the practice as fast as you can.
We all know that learning to divide into smaller user stories, and from user stories to tasks, takes time. It's not an easy thing to learn or to get used to. It truly is hard for them. They need to both learn the skill and to understand the value. We need to provide all the technical and theoretical assistance needed and do it fast.
While this issue can definitely be hotly debated, the fact of the matter is that there are lots of ways to deal with large stories. Field experts have written extensively about it already.
So what can we do about it in terms of mindset and resistance?
1. First, identify and acknowledge the smell. "we have an issue with dividing big chunks of work into smaller ones"
Don’t ignore it and don’t assume team leaders and/or developers will overcome it by themselves or just by reading an article. After all it’s a craft they need to learn and it takes time and requires the proper support.
2. Assign a technical mentor – someone who could get his hands dirty and help figure out patterns of splitting. Someone that can be available for a long period of time and trained for the craft or knows how to do it already. It may be a technical lead, CTO, Component Owner, whoever the team respects enough on a professional level to allow him or her to "step into their territory" without feeling threatened, instead feeling safe enough to cooperate.
3. Teach the techniques.
Explain the value of dividing big chunks into smaller ones: early feedback, higher quality work, delivering business value, etc.
Teach both the business side and the technical side, explain the value and the specific techniques out there.
It's better to do so using a real backlog example.
Here are some links for further reading on techniques of splitting big work into smaller chunks.
4. Invest in the product discovery and planning sessions so that developers will have more small "ready" stories to generate in the first place.
Make sure that during the ongoing discussions, as part of a discovery process or planning session there are people there who have the skill and those who lack it. The team discussion will expose those less skilled to the craft we would like them to acquire. There is nothing like ongoing real exposure to practice that is relevant to what you are going to work on next. It much better than a big chunk of training.
5. Engage other developers, who have experience in breaking large chunks of work into smaller ones, in group discussions.
6. Have a hackathon. Yes! A hackathon can have an amazing impact on this issue. It is fun, goals-oriented and requires presenting working software in a very short period of time. I will write a separate post on this matter, but suffice to say that having attended several hackathons in the course of my career has made me realize what a powerful tool this is for delivering this value precisely.
Agile engineering practices are designed to make software development teams to perform more efficiently. Those Practices serve as actual backbone for developing software in an agile way. There is no commonly accepted definition of what the agile engineering practices should be, but there are more then just few actually included and successfully used by agile teams. Here they are.
Sprint planning, an essential part of scrum where the entire Scrum team working together to answer the question of “What can we commit to?” In this Roojoom , I will provide examples of sprint planning , some tips and strategies for keeping sprint planning focused and effective and more. Enjoy.
Monday, March 16, 2015
What are those elements of a high performance organization, organizations that lead toward overall excellence? Part of being a High Performance Organization is being able to achieve high results, adapt well to changes, react on these quickly, continuously improving core capabilities and more…those are just some of the key elements of becoming an excellent performing organization. Here are those tips and insight on the subject.
Sunday, March 15, 2015
Now look at these surveys, how far has agile came from 2006 till now. Interesting.
Our history shows in reports: I have put together some interesting surveys about state of agile that gauge the value of Agile Development practices, methodology adoption, tools, state of adoption and more from 2005 till now.
Thursday, March 12, 2015
How exactly do you tell how mature an adoption of a specific Kanban practice is? How far are we on a scale from 0 to 5 with visualization? Why? What about subjective issues, how can we tell? So here is how:
Wednesday, March 11, 2015
Monday, March 9, 2015
Saturday, March 7, 2015
Managers are absolutely, 100% necessary in agile, but as an organization transforms to an agile way of working, functional managers can feel lost. Many of their traditional responsibilities move to other roles or disappear altogether.
So what does a 'good' agile practitioner manager do?
I think that if we really look at what a good manager does, it becomes clear how they work in a Scrum environment.
Let's look at this issue deeply and examine the various angels of a functional manager role in scrum.
Do you consider cultural differences while implementing scrum in your company? Whether it is in offshore solutions, distributed team, organization culture, industry culture or just team culture, You should. . The role of culture in agile methods and techniques is yet to be discovered and understood. Personally I believe that we can overcome almost everything applying the best approach to agility – after all , agile is a ‘suit we tailor and not a suit we buy’, and culture is something we need to take under consideration. Here’s what experts thinks about about the subject...
Tuesday, March 3, 2015
When is Scrum not appropriate and can cause more harm than good (generally speaking)?
I have been asked this question from time to time during first scrum tarring sessions. So I have decided to collect some answers from experts around the web. Not all of those answers are really a good fit to the question. Some of them are just a good indicator to a wrong implementation of scrum or misunderstanding of agile mindset. But just so you can relate to those pitfalls out there… here are certain situations where it doesn't seem like Scrum works well.
פורסם על ידי Shirly Ronen-Harel ב- 3/03/2015
Sunday, March 1, 2015
If you search Google for the "ideal sprint length" you will get varying results. Many people have different opinions on this and I truly believe that you should find the right balance for your organization or project. Traditionally you would try to reach some kind of happy medium for sprint length and that sprint would become the heartbeat of iterations for your software. So what is a good length? When to shorten it, how and why? Should it stay constant and more… all and more explained by the experts in this Roojoom.