Enterprises want to increase their capability to deliver value to customers in less time. Many adopt agile software development to iteratively develop and deliver software solutions. Lean startup aims to support developing new businesses and products. Several authors shared their views on how combining agile and lean startup methods can be beneficial.
Organization mostly do an agile transformation for a whole team, project, or organizational unit, given that agile is a team driven approach. But there are also professionals who start using agile practices individually, or who are working agile as a one person team. How can individuals adopt agile, and what kind of benefits can it give them?
The principle of “responding to change over following a plan”, is it a strength or a flexibility that can’t work in practice? For example, what about agile projects that had difficulties managing changes and customers who expect too much flexibility? Can agile not live up to its promises, or is it the way that teams and organizations have adopted agile that is causing the problems?
There are different types of pivots possible in lean startup, which help you to decide whether to persevere or pivot during product development. They each with their own purpose and ways to use them. Let’s explore some of them to see when and how you can pivot? Or maybe have to decide that it’s better to quit?
The priority game is an exercise which Michael Franken did at the GOTO Amsterdam 2013 conference, to make large backlogs manageable. He showed how Scrum can help you to focus and remove waste by not making things that are probably never used by customers.
Educational technology is developing itself, and startups are entering markets with new apps and creative commons content. Speakers shared their experiences on education and gaming and finding the right fit for an EdTech startup, at the GOTO Amsterdam 2013 conference.
Visure Solutions recently announced the availability of IRQA which denotes a solution for requirements definition and management (RDM). A sound process using professional tools is important for ensuring the quality of product and solution development with respect to the requirements specification.
On October 26th, The Jolt Judges announced the awards for 2011 in the category “Design, Planning, and Architecture Tools”. In detail, the Jolt hall of fame now includes the products Paradigm for UML, Restructure 101, and Requirements Center 2010.
Team Foundation Server 11 has added many features in the area of Application Lifecycle Management. Some of the highlights include support for code reviews, iterations/sprints, resource allocation, third part testing frameworks, and a much more capable dependency graph.
Recently, a proposal for the Requirements Modeling Framework (RMF) has been officially released by eclipse.org. Vision is to have at least one clean-room implementation of the OMG ReqIF standard in form of an EMF model and some rudimentary tooling to edit these models.
Non-Functional requirements are often associated with the state of the system and not with the functionality that the system has to offer. General 'ilities' of the system such as scalability, interoperability, maintainability, portability, performance and security fall under this umbrella. Agile teams usually struggle with defining and estimating the non-functional requirements in their projects.
Software Architecture is one of the important topics for software engineers, because many failures of software development projects are caused by inadequate design. Thus, it is essential to learn more about architectural issues in theory and practice. Interesting new books that have been published recently or in the near future could be very helpful
Mike Burrows started a discussion on the Kanbandev group which has led the community to explore the Expand / Collapse pattern. The discussion was covered elsewhere on InfoQ, in an article which followed the viewpoints of many practitioners who see more value in expansion than collapse. However, many people found both aspects of the pattern useful.
Agile methods recommend decomposing ("expanding") features into many small user stories. After the code has been written, however, should we collapse these small stories back into the original feature so we can deal with them all as a unit? Are there any advantages in doing that collapse, and if so, what are they?
Agile and Lean projects are run differently from traditional projects. But will those projects' contracts support or undermine Lean and Agile concepts? Here are some tips on how to write an effective contract for a Lean or Agile project.