curiouscat.com| John Hunter
Alumni| Investing|Travels| Recreation| Books| Lodging
Our Site
Management Improvement Library Management Glossary Books Management Blog Calendar Career - Jobs Learning
Management Library
Home Management glossary New articles Lean thinking Six sigma Deming Statistics Design of Experiments Podcasts Process Improvement Public Sector Improvement Reports
Topical Portals
Deming Lean Thinking Six Sigma Statistics Public Sector Community Quality
Links
Deming Lean Thinking Six Sigma Design of Experiments Health Care Public Sector Community Quality
Leaders
Ackoff Christensen Deming Drucker Goldratt Hamel Hoerl Ohno Womack
Management articles
software testing agile software development lean software development Deming lean manufacturing six sigma Design of Experiments (DoE) leadership process improvement statistics
curiouscat.com > Management Improvement > Software Development     Management Improvement Dictionary

Software Development Articles and Blog Posts

Read the Curious Cat Management Blog - software development posts.
Articles: agile software development - lean software development - software testing

  • Role of the Manager in Scrum   by Pete Deemer,   Jan 2010  
    "- Provide input to the Product Owner on the product strategy and vision, and give feedback to the Product Owner on the content and prioritization of the Product Backlog. - Provide support and assistance to Teams and their ScrumMasters. Be prompt and proactive in helping remove impediments that are harming Teams' ability to be effective. - Actively support ScrumMasters' efforts to protect Teams from disturbance, disruption, or outside interference..."
  • Lean Software Engineering - My progression toward Kanban   by Brian Doll,   Dec 2009  
    I was really impressed with how much work the various development teams could accomplish, given the fairly bureaucratic environment they were working in. Scrum brings some fairly specific and rigorous processes to agile development that appeals to the sensibilities of project managers. For developers used to working in waterfall or similar processes, this can be blast of fresh air... Developing software systems requires many different disciplines and no two projects or teams are the same. Spending time focusing on how you deliver value can dramatically increase your effectiveness and reduce unnecessary work, which reduces frustration. No matter where you end up, youll likely be happier than where you are now."
  • How I Hire Programmers   by Aaron Swartz,   Nov 2009  
    "If all that looks good and I'm ready to hire someone, there's a final sanity check to make sure I haven't been fooled somehow: I ask them to do part of the job. Usually this means picking some fairly separable piece we need and asking them to write it. (If you really insist on seeing someone working under pressure, give them a deadline.) If necessary, you can offer to pay them for the work, but I find most programmers don't mind being given a small task like this as long as they can open source the work when they're done."
  • Apple's Mistake   by Paul Graham,   Nov 2009  
    "The way Apple runs the App Store has harmed their reputation with programmers more than anything else they've ever done. Their reputation with programmers used to be great. ... There are a couple reasons they should care. One is that these users are the people they want as employees. If your company seems evil, the best programmers won't work for you. That hurt Microsoft a lot starting in the 90s. Programmers started to feel sheepish about working there."
  • The Way I Work: Jason Fried of 37Signals   by Jason Fried,   Nov 2009  
    "I spend another good portion of my day thinking about how to make things less complicated. In the software world, the first, second, and third versions of any product are really pretty good, because everyone can use them. Then companies start adding more and more stuff to keep their existing customers happy. But you end up dying with your customer base, because the software is too complicated for a newcomer. We keep our products simple. I'd rather have people grow out of our products, as long as more people are growing into them."
  • Taiichi Ohno Reinterpreted   by Keith Swenson,   Oct 2009  
    "if you understand the mapping to software development, you find that he sets out an equally clear description for Lean/Agile software development. If Ohno was alive today, I am convinced he would have been an eloquent proponent for developing software in short iterations, with continuous builds, continuous testing, immediate response to build breakage, and guided by feature burn-down. In other words, a proponent of Agile Software Development."
  • Exploding Software-Engineering Myths   by Janie Chang,   Oct 2009  
    "we also studied other existing assumptions in software engineering. They can be good or bad, because people make decisions based on these assumptions. Our primary goal was to substantiate some of these beliefs in a Microsoft context, so managers can make decisions based on data rather than gut feel or subjective experience."
  • I Come to Bury Agile, Not to Praise It   by Alistair Cockburn,   Sep 2009  
    Webcast: "Agile came from small, colocated projects in the 1990s. It has spread to large, globally distributed commercial projects, affecting the IEEE, the PMI, the SEI and the Department of Defense. Agile now sits in a larger landscape and should be viewed accordingly. This talk shows that landscape, clarifying how classical agile fits in and what constitutes effective development outside that narrow area."
  • The Unspoken Truth About Managing Geeks   by Jeff Ello,   Sep 2009  
    "IT pros are sensitive to logic -- that's what you pay them for. When things don't add up, they are prone to express their opinions on the matter, and the level of response will be proportional to the absurdity of the event. The more things that occur that make no sense, the more cynical IT pros will become... Presuming this is a trait that must be disciplined out of them is a huge management mistake. IT pros complain primarily about logic, and primarily to people they respect. If you are dismissive of complaints, fail to recognize an illogical event or behave in deceptive ways, IT pros will likely stop complaining to you. You might mistake this as a behavioral improvement, when it's actually a show of disrespect. It means you are no longer worth talking to, which leads to insubordination."
  • The Reality of Software Testing in an Agile Environment   by Kate Mackinder,   Aug 2009  
    "Testing practice for projects using agile technologies, treating development as the customer of testing and emphasizing a test-first design philosophy. In agile development, testing is integrated throughout the lifecycle, testing the software throughout its development... Myth Four: 'Unit tests remove the need for manual testing' Manual testing is a repetitive task; it's expensive, boring and error-prone. While TDD can reduce the amount of manual effort needed for functional testing; it does not, remove the need for further black-box testing (manual and automated)."
  • Combinatorial Software Testing   by Rick Kuhn, Raghu Kacker, Yu Lei, and Justin Hunter,   Aug 2009  
    While the most basic form of combinatorial testing, pairwise, is well established, and adoption by software testing practitioners continues to increase, industry usage of these methods remains patchy at best. However, the additional training required is well worth the effort. Teams seeking to maximize testing thoroughness given tight time or resource constraints, and which currently rely on manual test case selection methods, should consider pairwise testing. When more time is available or more thorough testing is required, t-way testing for t > 2 is better.
  • Kanban Software Development Oversimplified   by Jeff Patton,   Apr 2009  
    "Recently I've heard lots of discussion about Kanban style development - an approach that breaks that breaks the primary rule of today's common agile practice: the fixed development time-box... It's common for Agile teams to put the stories in a current time-box on a board with columns for the stages stories go through such as "development" and "testing." The Kanban board is similar - with a few more rules..."
  • Getting Management and Engineers Out of Each Other's Hair   by Damon Poole,   Jan 2009  
    "Instead of a manager having to unearth all problems and come up with all solutions, a retrospective accomplishes much of this, providing the manager with more bandwidth to deal with sensitive issues and to focus on people management. Retrospectives are particularly effective when combined with short iterations because problems have less time to fester and there are more opportunities to take corrective action."
  • CMMI or Agile: Why Not Embrace Both!   by David Anderson, Hillel Glazer et. al.,   Nov 2008  
    40 page report from the Software Engineering Institute. "The purpose of this report is to clarify why the discord need not exist and to ask for your help in making the software development community aware that, when properly used together, CMMI and Agile can dramatically improve performance... When viewed holistically, CMMI's ultimate goal (i.e., continuous process improvement) is to cause an organization to become less wasteful, leaner, and more in touch with actual development progress. Ultimately, both Agile and CMMI, especially in high-trust environments, expect organizations to see gains in productivity by eliminating unnecessary effort. It's true that implementing Agile methods will often eliminate many unproductive efforts and behaviors at the project level."
  • Your Code Sucks and I Hate You: The Social Dynamics of Code Reviews   by Jonathan Lange,   Sep 2008  
    "Code reviews provide an amazing opportunity to grow as a programmer and to improve the software we make. There are many choices that a project can make about how reviews are done and what they can achieve."
  • The Role of Leadership in Software Development   by Mary Poppendieck,   Nov 2007  
    "In this 90-minute talk from the Agile2007 conference, Lean software thought leader Mary Poppendieck reviewed 20th century management theories, including Toyota and Deming, and went on to talk about 'the matrix problem', alignment, waste cutting, planning and standards. She closed by addressing the role of measurement: 'cash flow thinking' over 'balance sheet thinking'."
  • Visualizing Agile Projects using Kanban Boards   by Kenji Hiranabe,   Aug 2007  
    "I'll discuss Kanban Boards as the main information radiators, and Burndown Charts and Parking lot Charts as sub-tool which summarize Kanbans visually... A project team consists of people working toward the same goal. Typically, a manager, customers, developers, business analysts, users, testers and other stakeholders should be members of the team. The whole team should share information on time and tasks to achieve the project goal..."
  • Agile 2007: Agile practices travel full circle   by Tony Baer,   Aug 2007  
    "Specifically, while lean manufacturing allows you to have a long range forecast for inventory requirements and demand, it forces to you to work with only enough stock to fill firm orders that are in the short-term pipeline. Likewise, agile software development allows you to have high-level requirements and roadmaps for a software project, but only gets specific with 'stories' that are developed for each iteration, or sprint."
  • Lean for Software: Interview with Mary Poppendieck   by Peter Abilla,   Feb 2007  
    "But the fundamental Lean principle in product development is that we should not make any design decisions until we absolutely have to. We really do not want to have decided anything until we need to; and so at the point it time of the decision we should still have 3 options. Still have a couple of middleware options, or still have not decided how we're going to do the user interface. You wait until you know the most possible information before you make decisions. So, the idea of having a complete detailed spec at the beginning is the exact opposite of the Lean commitment."
  • Toyota IT Overview   by John Hunter,   Sep 2006  
    "Customize the code, to business processes: not the other way around. Yes. Yes. Yes. IT should support your processes not dictate them. I am a big fan of avoiding inflexible, proprietary (off the shelf) software. I am willing to spend money on in house developers to create customize IT solutions that support the business processes instead of IT solutions that dictate business processes."
  • Lean for Software   by Mary Poppendieck,   Sep 2006  
    "I believe that the measurements imposed by traditional project management methods are the biggest impediment to the successful implementation of lean development. In particular, instead of measuring variation from plan, we need to start measuring the delivery of realized business value."
  • The Declaration of Interdependance   by Alistair Cockburn,   Jun 2006  
    "Lean manufacturing teaches us that having large inventories is inefficient. It also teaches us that the overall efficiency of a process improves as the batch size passed from stage to stage is reduced. Today this has become accepted in most (but not all) manufacturing circles, yet many people may be surprised that it also applies to software development."
  • Stretching Agile to fit CMMI Level 3   by David J. Anderson,   Jul 2005  
    "At Microsoft, we've adopted the teachings of W. Edwards Deming and stretched our MSF for Agile Software Development method to fit the requirements for CMMI Level 3. The resultant MSF for CMMI Process Improvement is a highly iterative, adaptive planning method, light on documentation, and heavily automated through tooling."
  • Making the Business Case for Agile Management   by David J. Anderson,   Jul 2004  
    "Agile Management seeks to make a paradigm shifting change in the approach to management of software engineering using best practices in management science including the true definition of value, the concept of a value chain, systems thinking and a focus on quality through an understanding of variation."
  • Lean Software Development   by Mary Poppendieck,   Sep 2003  
    "All lean thinking starts with a re-examination of what waste is and an aggressive campaign to eliminate it. Quite simply, anything you do that does not add value from the customer perspective is waste."
  • Managing Change Requests Using Lean Methods and a Kanban Board   by Eric Landes,   Nov 2002  
    "Existing Agile techniques assume a team working on one project, not an enterprise team working on multiple applications. There is another agile way to mitigate these issues. You will explore how to use the lean artifact Kanban board to manage your software's change requests."
  • Scrum-ban   by Corey Ladas,   Nov 2002  
    Great article on lean software development ideas: "One simple technique that brings us much closer to our kanban definition is to set a multitasking limit for individuals. You might have a simple principle like: prefer completing work to starting new work, or you might express that as a rule that says: try to work on only one item at a time, but if you are blocked, then you can work on a second item, but no more. In our example, that rule gives us an effective WIP limit of 6."
  • Rapid Application Development: Project Management Issues to Consider   by Patricia A. McQuaid,   Jun 2001  
    "Successful rapid development starts with understanding and defining the client?s business needs, and then moves through the phases of high-level requirements to detailed requirements, to design, to prototyping, to development, and to implementation."
  • Lean Programming - part 1 of 2   by Mary Poppendieck,   May 2001  
    "Assembly-line production techniques apply to software, too."
  • Lean Programming - part 2 of 2   by Mary Poppendieck,   May 2001  
    "Total Quality Management still rings true for software." Not a perfect represenation of Deming's ideas (in our opinion) but an example of Deming's ideas continuing to spark interest.