“Developing a product takes time. The only way to do it is to experiment. Build a prototype or a sample and show it around. Let people kick the tires, touch it, feel it. Let them get a taste of the product. Get their feedback and incorporate it into the next prototype you build. Do it fast.” Sounds like something a Lean Startup practitioner would advocate, doesn’t it? But, you see, I got this from someone who worked in manufacturing all his life and never heard the term “Lean Startup”.
He went on to say, “You’ve got to listen to the people doing the work. They do this day in and day out. If you want improvement ideas, listen to them. Solve their pain points and see productivity increase.” Sounds like agile thinking, right? With the right attitude, one can adapt the learnings across industries. Continue reading “The agile mindset – what does it mean?”
“We are Agile. We don’t need to follow a process”, declared Chris.
Tina was aghast. “How do you think we deliver solutions, Chris?”
“What do you mean? We do Agile. We follow Scrum. We don’t follow processes like the Waterfall guys do. We neither need a whole lot of planning nor documentation. We don’t do BDUF (big design upfront). We love to code and that’s what we do”, responded Chris.
He would have continued, but Tina interrupted it.
“Ok. Let’s get this straight – you think if you follow the Scrum practices to develop software, you are agile?”, she asked. She decided not to pursue the “do Agile” line of questioning.
“Yes”, responded Chris.
“And you think if you follow the Scrum practices, you are not following process?”, she asked.
“Yes”, asserted Chris.
“And you think neither planning nor documentation is essential?”, Tina pushed along.
“Yes”, said Chris.
“Fair enough”, said Tina. “Let’s look up the definition of process, shall we?” Continue reading “The value of value stream mapping in software engineering”
We let it slide for a while. A few months actually. The Kanban board my daughter uses to track her daily work. A few weeks ago, she insisted we bring it back. When asked why she wanted the Kanban board back, she promptly replied, “I love moving the sticky to Done.” Can’t argue that. And so we brought it back.
She made changes to the board and how she wanted it to look like. At the top of the board she has a weekly plan of all the things she decided she wants to do. (see figure below). This is her weekly backlog. While I have broken it down by day to make it easy for her to follow it – she is 7, she gets to decide on the order it which she wants to do some of them. Her board has 3 columns – To Do, Doing, Done. Continue reading “Journey to becoming a lean & agile family”
Does this scenario sound familiar?
- Your account management/sales team has committed delivery to a customer on a certain date
- As you get closer to delivery, realization dawns that the commitment is in jeopardy
- Work is expedited. Wait a minute! Now that you stop to think about it, someone is always expediting work to meet delivery commitments
- “We need more people” constantly echoes down the hallways
- Coordination between various teams to deliver your project or product is a herculean effort; work appears to be backed up randomly within different teams
- Project is a wreak
- After weeks and weekends of frantic activity, the lessons learned are the usual suspects: get better at estimating, hire more people, add more process to ensure accountability or a variation thereof
- Your account management/sales team has committed delivery to a customer on a certain date …
This never ending loop continues. You know what I am talking about. You’ve been there. I can, however, guarantee you that you have more capacity that you think. You don’t need to hire more people to improve throughput. On the contrary, you need to reduce your work-in-progress. Counter intuitive? Yes. I can tell from experience that it is true. Why don’t you try it out yourself – within your span of control? Experiment, learn, adapt. Continue reading “Kanban your way to breakthrough profitability”
If you believe that change is the only constant, ever so often, we need to push ourselves out of our comfort zone. We need to tell ourselves, “I am not entirely sure how this is going to play out. But we need to do something different to achieve (insert your business objective here) because the current way of doing things isn’t doing a great job of keeping us one step ahead of our competition.”
When I was invited to speak at the Project World Business Analyst World in Moncton this year, I chose to talk about my experiences adopting lean and agile tools and moving away from waterfall where it makes sense. Now, delivering a session at any conference typically follows a similar routine. Submissions from speakers are invited. A selection committee reviews and selects the speakers. The speaker prepares a PowerPoint. At the conference, the talk is dominated by the speaker with questions from the audience sprinkled in. This is beginning to look like a waterfall approach.
Continue reading “My Project World Business Analyst World talk: from waterfall to agile”
Introducing agility into traditional systems development processes is never easy. Firstly, you have got to want to change. Secondly, you need to have a vision of what to change to. Finally, you need the tenacity to forge ahead in the face of stiff resistance. It is usually the third that is the most difficult journey to undertake. The hardest part of the journey is during the transition wherein you show how to bring agility into executing projects. You are walking the fine line between traditional methodology and incrementally introducing change.
One of the challenges during the transition is the question,” how do I know if the project is on track?” Despite all the conversations around introducing agility, when the rubber hits the road, it always comes back to “are the tasks on the critical path late?” or “what’s the project CPI and SPI?” or a variation thereof. Critical path and earned value concepts are deeply ingrained into our psyche. It is not easy to let go. Continue reading “Transforming from waterfall to agile”
Joe sighed and returned to his desk. He had been waiting for Jane to provide him with information for the last two days. If Jane could only take a few hours to do it, he could get on with his work and check it off his list. Instead he would now have to wait for a week before Jane can even look at it. He would just have to tell Smith this project deliverable will be delayed. The customer is probably not going to be happy about it, but there is nothing he could do about it. Reaching his desk, he put this work aside and stared at the pending work list wondering what he could do next that can be completed. The list continued to grow. We need more people, he thought as he eyed his manager walking towards him.
Jane shook her head in frustration. She wanted to help Joe out; in fact she had been scheduled to work on Joe’s stuff, but was pulled away on other priority work. Glancing at the work requests piling up, she thought, we need more people.
Donald, the CEO, sat staring at the phone. He just got off the phone with one of the customers. The project team had missed the delivery for the third time. And this was not the only project that was in trouble. “This is crazy. What”, he thought, “were we doing wrong? Why can’t we seem to get our act together and deliver projects to the plan? We should plan better. I better find Smith and find out what’s going on.”
Continue reading “The power of pull”
Ask any project manager the reasons why projects fail and one of the reasons cited will definitely be scope creep. But is scope creep really that bad? I don’t think so. Your view of the scope creep will depend on how you manage projects. You can manage projects as a contract or you can collaborate.
I think there will be a scope creep when there is a contract between the solution provider and the consumer. For example, it is notorious in the construction industry. In fact, some contractors want the consumer to change the scope in the middle of the project. That’s their way of making money; it is not like you are going to change contractors in the middle of the project. But if both parties collaborate, then scope creep as a reason for project failure just melts away. Continue reading “Scope creep? Bring it on”