Telerik blogs
  • Productivity

    Thoughts on Agile User Stories and High Bandwidth Communication

    I like agile user stories. They make sense to me. 15 years ago – I wrote a lot of “Use Cases”. As use cases seemed to have some components I liked – they frightened and intimidated me - I found that as use cases would gradually become more complicated and cumbersome to write – I spent all my time writing, debugging, and maintaining them – yet, I found I was still not communicating with my customer or my development team very well. Quality didn’t improve. We still were at risk of building the wrong product. Agile User ...
  • Productivity

    Top 5 Challenges of Adopting Agile Methodologies

    The hardest part of adopting Agile methodologies is getting started. In this presentation Joel Semeniuk, Executive VP of Telerik's Agile Project Management Division, focuses on the hardest parts of getting started. You will learn what the most common problems for teams getting started with Agile are and how to deal with those. Some of the areas discussed are planning, productivity, and requirements gathering.
  • Productivity

    Self-Organizing Teams Focus on Learning

    Most Agile texts/guidance/speakers (including myself) stress the creation and sustainment of self-organized teams. What does this mean? Is this possible? Can this ever be achieved? I’ve seen many teams evolve to Agile teams over the years. I must say, Team organization and Team management (especially self-organized teams) is quite difficult and absolutely the single most important aspect of success. The teams that I’ve seen succeed have a few characteristics that are in common.“… learning is key to having a self-organized team” First, there is usually a really great Scrum Master/Agile Coach involved at the beginning of a good self-organizing ...
  • Productivity

    How can we commit if we don't have all requirements?

    I get asked this a lot.  Project Managers are asked to provide full project plans and are asked to commit to this plan.  In order for Project Managers to feel good about this, we try to get all of the requirements up front.  This allows them to derive a schedule and a cost for developing these requirements.  This makes perfect sense right?  If that’s the case, how in the world can an Agile team commit to a project that has a fixed cost and schedule?  Here is the assumption – if we figure out the requirements – we can derive ...
  • Productivity

    Can’t Fit it all into a Sprint?

    Agile teams like short iterations because they help to ensure tight feedback cycles in order to reduce waste and minimize uncertainty. However, what if you can’t fit all the work required to implement a product backlog item in a 2 week sprint? For example, with more and more emphasis on design a considerable amount of work might be required for a designer to work with the product owner prior to any development effort investment. A similar question was asked of me during a web cast on Agile adoption: “... it’s a challenge to incorporate integration testing in a short 2-4 ...