Subscribe: Comments for Lean Software Engineering
Added By: Feedage Forager Feedage Grade B rated
Language: English
agile  comment scrum  comment  development  evo  management processes  management  plan  process  processes  project  scrum ban  scrum  time 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Comments for Lean Software Engineering

Comments for Lean Software Engineering

Essays on the Continuous Delivery of High Quality Information Systems

Last Build Date: Fri, 20 Feb 2015 21:57:18 +0000


Comment on Boehm’s Spiral Revisited by Wireframing & Prototyping: The Past, Present, and Future - Web Based Coding, LLC

Fri, 20 Feb 2015 21:57:18 +0000

[...] Source: Boehm’s Spiral Revisited [...]

Comment on Scrum-ban by Anonymous

Tue, 24 Jun 2014 01:16:45 +0000

Thank you for this excellent article. I find myself returning to it repeatedly to clarify my thinking or to explain Lean/Kanban principles to others.

Comment on Scrum-ban by Revue de Presse Xebia | Blog Xebia France

Tue, 14 May 2013 08:00:58 +0000

[...] traduction de Fabrice Aimetti, de l’article de Corey Lada "Scrum-ban", décrivant toutes les étapes du passage d’un processus Scrum à un flux tiré kanban, [...]

Comment on Tom Gilb’s “evolutionary delivery,” a great improvement over its successors by ReBytes

Tue, 30 Apr 2013 09:33:35 +0000

In my quest to revive the best of the best I will give some thoughts here. I don't batter other agile processes here, I purely give accounts of my experiences over the years. I agree with writer that other agile processes are very weak and unfortunately only a gimmick. Let me explain. 1) They all use what I call "lazy management". Only worry about what is outstanding and what needs to be done next. I have not found one institution which implemented an agile methodology with proper metric management and feedback into the process. Why? Because when you read the documentation it sounds to complicated. 2) You read everywhere that SCRUM is working great or XP showed great results. It is all just denial. How can your process be great if after 3 years you still need to say "We saw some benefits but are still learning how to get the most out of it". That line says that you are still overrunning on projects and have no handle on managing the project. Evo according to the Gilb's is not a developement process. It is only a management process which you can use together with any development process. Evo conentrate on the metrics and how to know if you are moving closer to your goals. Then Evo have some principles which describes what important attributes a development process must have to get the most out of Evo management processes. If you ask most agile project managers what the difference is between software management processes and software development processes they will probably answer "It is all an integrated process in agile" or "There is not a difference or if there is its a very gray area". In the 80's Evo had its time and numerous big institutions used Evo management processes with their own proprietary development processes, and this is why Evo never became popular. No-one thought that by improving your management processes it will lead in you optimizing your development processes. Everyone was looking for the silver bullet, the one process that would fix all and then Agile fell into our laps. If you reflect on it you will realize that Evo was actually 20 years ahead of its time. And like most things ahead of its time (like the Microsoft tablet) it got lost. Why dont people go for Evo now if it is the best. Because if they see "from the 80's" they think waterfall or spiral models and dont read on. That is why a revival campaign is needed. I love software processes and have been investigating them for the last 12 years on my own. I will never claim that I am an expert of anyone but I know why the most dont work. I never could get the real grasp on SCRUM and XP when they started to become the silver bullet in the early 2000's. That was until I stumbled upon Evo. After reading about Evo I immediately saw what SCRUM and XP tried to solve and why they failed. I myself used various agile methodologies and saw very little success. I always believed that agile is the way forward, but with a little better structure and guidance. Currently for my personal projects I only use Evo management processes with a development process I created from the 10 principles that Evo recommend. Evo with the 10 principles just placed that little bit of structure ontop of an agile methodology to make it great. As soon as the false publicity about the success stories of current mainstream agile processes dies out, Evo will be seen as the missing link that is needed together with an agile process to make the development process work.

Comment on Scrum-ban by Kanban – The Hard Way! | James Philipps

Wed, 25 Jul 2012 11:03:49 +0000

[...] being more work-focused than people-focused (indeed, a merging of the two techniques exists called Scrum-ban  , focused on getting the best of both [...]

Comment on Planning a month or less ahead is not enough by Jawad Habib

Thu, 12 Jul 2012 00:23:53 +0000

I have several questions for you from the section I quoted at the end of my post below. How do you define over planning? Why is it disastrous? A good plan should help to establish a baseline which can change over the project's lifetime as business needs and priorities evolve. A plan is, to me, simply a snapshot, at a certain point in time, of a future desired state, available resources to achieve that desired state and an estimated timeframe for getting to that state. This snapshot also helps to lock down constants and variables e.g. timeframe may be constant while features and resources variable, or a combination thereof. When changes do occur, the project team needs to evaluate the impact and socialize this with the stakeholders. A good baseline and a quantiative evaluation of the change would help to show why, for example, project delivery is being pushed forward. A vauge, or a very high level, project plan would not provide a clear picture of what will be achieved when the expected time and resources are spent on development. Now think about this in an environment where projects have finite budgets for development and some expected benefits (revenue projections, for example) that need to be derived by the business. How would the business approve budget for a project where there are lots of unknowns? For example, would you ask the business to give you $100 to spend and in turn they will get something in some time, without really know what and how long? Or would you propose to the business that they will get A, B and C features but they have to spend a yet unknown sum of money and time to get those features? What if they lose the chance to earn projected benefits by the time your project is completed. I think a well established project plan helps the business understand what they will get and how much time and money they will have to spend to get that. The change management process, which is usually part of the project plan, tells the business how changes will be managed over the course of the project. I think the key here is visibility into the process that you do adopt. Very few businesses would approve unlimited sums of money and an infinite amount of time to get a not-so-well-defined set of features. I've always thought of Agile as a way to manage day-to-day development work rather than something that replaces due diligence for managing projects. Your thoughts appreciated. Quote "Unfortunately, what you may know (but isn’t obvious to everyone) is this over-planning can be disastrous when there is any level of risk or significant unknowns. Almost any non-trivial software development project would fall in this category. Usually, this highly detailed initial plan falls quickly out of touch with reality, and must be ignored by the team after a certain point. Good project managers will try to adapt the plan, but if they built in too much detail initially, they’ll find keeping it up to date impossible. Either way, this all can be damaging, as now the team often feels like they’re confused and failing, and management or stakeholders can quickly get dangerously out of touch — they’re still looking at and expecting that initial plan."

Comment on Scrum-ban by Evan

Thu, 07 Jun 2012 12:44:43 +0000

Works great when you only have 10 features that can be explained on a post-it note.

Comment on Scrum-ban by Kanban IT Literaturliste | GAMEDEVELOPERS COMMUNITY

Sun, 03 Jun 2012 16:07:16 +0000

[...] Scrum-ban [...]

Comment on Feature Crews: kanban systems for software engineering in the large by The Visual Studio Blog

Tue, 29 May 2012 05:34:41 +0000

Visual Studio Sessions at PDC ‘09... The Professional Developers Conference (PDC) this year is in Los Angeles from November 17 th to 19 th...

Comment on Pugh Decision Matrix by Pugh engineering | Youtoobelong

Sun, 13 May 2012 09:33:34 +0000

[...] Pugh Decision Matrix | Lean Software EngineeringCombat Systems Engineering. We are a small group of experienced professionals that provide consulting services for the U.S. and F.M.S.. Key areas of … [...]