Does Agile provide any benefits in work which is research driven? Is there any point in using Agile when you know you can’t have potentially shippable increments every 1-4 weeks? How can it help stakeholders set constraints in research driven work, so that the work doesn’t drag on? How can hypothesis-driven development, and set based design help? Have a look at these in the context of Apple device research and development.
Though both are scaling frameworks, SAFe and LeSS target two different local optimums. Does SAFe really aim to reduce bureaucratic control enough to move the organisation away from the traditional optimum or does it only try to optimise the existing organisation by creating Lean-Agile programs? Doe LeSS inherently reduce the bureaucratic control? A very interesting perspective.
Change is neither easy nor fast, especially when we are dealing with large enterprise systems. We are normally constrained by existing, older, and fragile technology, and little time. Just saying, we are “doing Agile” doesn’t mean our enterprise architecture will become lean and Agile overnight. How do we foster relationships between development teams and the business in a lean way? How to create and share an architecture vision? How to build bridges, between what we have and the to-be state? Here are a few ideas.
Scrum is one of the most commonly used Agile framework. It’s the one that sparks most debates. There’s no shortage of Scrum critics – the debate rages on. Is there anything fundamentally broken in Scrum? If the answer is yes, then what is it? More importantly, how to fix what’s wrong with Scrum?
Wouldn’t it be cool if your teams can move move from problem to idea to prototype to feedback, in just 5 days? And then iterate from there. Google Ventures came up with the idea of Design Sprints to help their startups achieve this. These stem from design thinking championed by Ideo. Here’s how it works.
Paper prototypes allow teams to iterate quickly on the design, and find the best-of-breed with minimal investment. It is quick, fun, and easy to learn. Here’s a look at how Mozilla used paper prototyping, combined it with user research and data mining to quickly advance the UX redesign of a major part of its website.
Well, with a lot of manual work, and without a lot of computers. Yes, that’s correct. Toyota only automates dangerous work and the work that http://www.nngroup.com/articles/mozilla-paper-prototypeinvolves heavy loads. All other work is done by humans, because humans can improve the way they work. This is a fascinating account of a factory which produces 40000 vehicles, without a lot of automation, with 6000 employees. And yes, they do stop assembly lines there. This article is from 2008, but Toyota works to a 50 year plan, so they’d only have improved the process by now.
We know the drill. Everyone answers three questions during the Daily Scrum. This plain vanilla Daily Scrum is pretty good. What if we try some Lean practices to make this even better? Like, focussing on single piece flow. Here are some ideas on how you can get started, and make your stand up even better.
Legacy code is full of mysteries. What about that weird if statement that seems to do nothing anymore (it was introduced as a workaround for a creepy bug that has now been fixed). All the history that’s often lost over time is what causes issues. Eventually we end up in a mess. What can we learn from forensic psychology that can make our job easier? Here’s an interesting perspective.
Complexity is one of the major cause of problems in software development and maintenance. It leads to unreliability, late delivery, lack of security and poor performance. So how do we tame complexity? What’s even more important to understand is that what causes the code to become too complex in the first place? Once we understand that, we can avoid those traps. Here are a 9 things to watch out for.
To celebrate Issue number 50, here are top 10 most read pieces from those 50 issues. The journey goes on.
AGILE
How Can Apple Use Agile in R&D?
Does Agile provide any benefits in work which is research driven? Is there any point in using Agile when you know you can’t have potentially shippable increments every 1-4 weeks? How can it help stakeholders set constraints in research driven work, so that the work doesn’t drag on? How can hypothesis-driven development, and set based design help? Have a look at these in the context of Apple device research and development.
blog.agilegamedevelopment.com
Middle Management & Bureaucracy – LeSS Vs SaFe
Though both are scaling frameworks, SAFe and LeSS target two different local optimums. Does SAFe really aim to reduce bureaucratic control enough to move the organisation away from the traditional optimum or does it only try to optimise the existing organisation by creating Lean-Agile programs? Doe LeSS inherently reduce the bureaucratic control? A very interesting perspective.
gosei.fi
How to Make Enterprise Architecture Lean?
Change is neither easy nor fast, especially when we are dealing with large enterprise systems. We are normally constrained by existing, older, and fragile technology, and little time. Just saying, we are “doing Agile” doesn’t mean our enterprise architecture will become lean and Agile overnight. How do we foster relationships between development teams and the business in a lean way? How to create and share an architecture vision? How to build bridges, between what we have and the to-be state? Here are a few ideas.
martinfowler.com
What’s Wrong With Scrum?
Scrum is one of the most commonly used Agile framework. It’s the one that sparks most debates. There’s no shortage of Scrum critics – the debate rages on. Is there anything fundamentally broken in Scrum? If the answer is yes, then what is it? More importantly, how to fix what’s wrong with Scrum?
ronjeffries.com
How Design Sprints Work at Google?
Wouldn’t it be cool if your teams can move move from problem to idea to prototype to feedback, in just 5 days? And then iterate from there. Google Ventures came up with the idea of Design Sprints to help their startups achieve this. These stem from design thinking championed by Ideo. Here’s how it works.
agilemarketing.net
PRODUCT OWNER
Effective Paper Prototyping. Mozilla Case Study
Paper prototypes allow teams to iterate quickly on the design, and find the best-of-breed with minimal investment. It is quick, fun, and easy to learn. Here’s a look at how Mozilla used paper prototyping, combined it with user research and data mining to quickly advance the UX redesign of a major part of its website.
nngroup.com
LEAN
How Does the Most Profitable Toyota Factory Work?
Well, with a lot of manual work, and without a lot of computers. Yes, that’s correct. Toyota only automates dangerous work and the work that http://www.nngroup.com/articles/mozilla-paper-prototypeinvolves heavy loads. All other work is done by humans, because humans can improve the way they work. This is a fascinating account of a factory which produces 40000 vehicles, without a lot of automation, with 6000 employees. And yes, they do stop assembly lines there. This article is from 2008, but Toyota works to a 50 year plan, so they’d only have improved the process by now.
kevinmeyer.com
Using Lean to Improve Daily Scrums
We know the drill. Everyone answers three questions during the Daily Scrum. This plain vanilla Daily Scrum is pretty good. What if we try some Lean practices to make this even better? Like, focussing on single piece flow. Here are some ideas on how you can get started, and make your stand up even better.
scrumalliance.org
DEVELOPER
What’s Common Between Code and Crime Scene?
Legacy code is full of mysteries. What about that weird if statement that seems to do nothing anymore (it was introduced as a workaround for a creepy bug that has now been fixed). All the history that’s often lost over time is what causes issues. Eventually we end up in a mess. What can we learn from forensic psychology that can make our job easier? Here’s an interesting perspective.
dzone.com/articles
How to Overcome Complexity to Become a Better Developer
Complexity is one of the major cause of problems in software development and maintenance. It leads to unreliability, late delivery, lack of security and poor performance. So how do we tame complexity? What’s even more important to understand is that what causes the code to become too complex in the first place? Once we understand that, we can avoid those traps. Here are a 9 things to watch out for.
https://dzone.com
Share this: