AMT Blog

Programmers, explicitly or implicitly, while working on complex systems, end up designing some APIs to accomplish their tasks, either because the product itself is some kind of general purpose library or because they need to write some libraries and packages to put some common code of their applications.

There is plenty of information available about how to write good code, unfortunately, it is not always clear how to apply that information in practice. This presentation by Giovanni Asproni at Agile Cambridge 2011, aims at giving some practical advice, and also shows how an agile incremental approach makes it easier to produce APIs that will stand the test of time.

Click here to download:

writing-usable-APIs-in-practice.pdf (1.14 MB)

(download)

Click here to download:

writing-usable-APIs-in-practice.pdf (1.14 MB)

Read more…

Like what we post? Share your thoughts on the comments below. If you wish to get regular updates on what we post, do subscribe to our RSS Feed

IMVU is referred to as the first “Lean Startup”, and was the proving ground for applying Build-Measure-Learn (the Scientific Method) to rapidly iterate and continuously improve its product development process, resulting in a valuable strategic advantage and highly productive, happy, and motivated teams.

This Slideshare Presentation focuses on IMVU’s continuous improvement to product development process through experimentation. Success factors are reviewed, including a culture that values and supports experimentation and learning, Agile and XP engineering practices (which support iterative development), and strong product vision and user experience design. Recent product development process experiments will be shared.

Takeaway: Attendees will learn how IMVU continuously improves product development using the Scientific Method, Agile, XP, and Scrum supported by strong user experience design. Strategies to support experimental learning (retrospectives, postmortems, and 5 Whys) will be reviewed along with practical examples

In this screencast, we start by reviewing the company culture model created by William Schneider and then use it to understand the Agile Manifesto, the Manifest for Software Craftsman and Kanban Principles to understand what their implied cultural bias.

For more information, please see Agile Culture Series Reading Guide.

This is an interesting article which originally appeared on CM Crossroads written by Monika Konieczny. Here the author explores how the simulation games can actually help an agile team communicate better in the long run.

One of the hardest daily tasks developers, QA, ScrumMasters, and product owners encounter is  effective communication with others.  Sound implausible?

According to many articles [6][7][8][9], research, and personal observations, the main cause of project failure is not technology or hardware but inefficient communication stemming from lack of effective communication between team members, incomplete business analysis and imprecise requirements, and vaguely formulated business objectives.

That's why so many people put a lot of effort in finding the holy grail—efficient methods of improving communication skills.

Optimization of the communication process includes several phases:

Analyzing the initial situation;

• identifying weak points;
• creating, reviewing, and evaluating new procedures;
• and introducing changes.

To make each phase easier, we can use simulation games. These games are a form of competition in which rules are fixed and agreed on by the participants. This is an example of a heterogeneous simulation model, whose key elements are the participants and game mechanics.[1]. Game mechanics (i.e., rules) can be adapted to the specific needs of the team. Players have defined roles and goals—either private or shared with the team.

Assume the goal is to optimize communication on your team. In the first phase, participants should use  their current procedures. During the next stages, they should have a chance improve those existing procedures or design new ones. The aim of the final stage is to verify the new solutions defined in the previous stages. Participants will have the opportunity to look at selected issues from a different perspective (e.g., from the perspective of a person acting in a different role in the team). Using that information, the team has the opportunity to work out effective methods of communication and integrate the new solutions…

Read the Complete Story…

Don't like to miss out any of our posts? Do Subscribe to our Feed

Take a look at the slides Roy Osherove used during his latest talk at QCON london 2011 :

In this talk he explores the three maturity stages of a software team, and how a team leader can adjust their leadership type based on the current phase the team is in. I also explore common mistakes and techniques team leaders can take to make sure their team gets on the road to craftsmanship and maturity in software development.

 The Topics covered here includes:

• The three maturity stages 
• What are you going to do about it?
• My team keeps breaking their promises
• Steps to take on a chaotic team