Skip to main content

Home/ Agilesparks/ Group items tagged resting

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Yuval Yeret

Using a Task Board with One Remote Team Member | Mike Cohn's Blog - Succeedin... - 0 views

blog.mountaingoatsoftware.com/rd-with-one-remote-team-member

physical taskboard

shared by Yuval Yeret on 01 Jun 09 - Cached
  • Try to get the one person to move to where the rest of the team is.
  • Having one remote is a cost that must be borne by the full team. For the right person, it’s easily worth it. But sometimes, the person who is remote has not special skills, knowledge or experience to justify the added hassle.
  • continue to use the physical task board–it is simply too beneficial to the collocated team members to give it up in favor of a product backlog tool, especially if team members are already used to it and like it.
  • ...3 more annotations...
  • The remote person in this case could identify during the daily Scrum what he or she will work on and not need further interaction with the task board until selecting the next task. Here, the remote person doesn’t really interact with the task board at all and interacts only with the team. Not ideal as I’d like the person to see the tasks, but this can work in some situations.
  • more common is for the ScrumMaster to take on the responsibility of updating an electronic version that mirrors the physical task board
  • One good way of minimizing the time the ScrumMaster spends doing this is to mark the cards on the physical task board. The mark indicates “I’ve updated this task. Please update it in the online task board.” I like to use Post-It flags for this
Yuval Yeret

CIO Perspectives: A Conversation on Agile Transformation, Part 2 - 0 views

www.borland.com/...cio-perspectives-part-two.html

agile transformation

shared by Yuval Yeret on 15 May 09 - Cached
  • Part 2
  • The thinking is that IT is mission-critical, so let's not change things without giving it a lot of thought and a lot of consideration
  • The really hard part is around the people transformation - getting developers to work side-by-side with testers and users is a completely foreign concept.
  • ...8 more annotations...
  • The reason there's been so much turnover of CIOs in the last ten years is because the end users – the CEOs, the CFOs and the division heads – are unhappy with the results. When IT professionals realize this, and realize that something like Agile gives them the opportunity to create better value for their businesses, then they're going to be a lot more willing to adopt it. I hope that development organizations are starting to see around that corner.
  • We WANT to go Agile. How do we overcome the skepticism at the CXO level?"
  • My recommendation would be "try it." Agile doesn't equal risk, but changing development methods does equal some risk
  • t can be a big deal to say: "I'm going to change our development methodology." It makes people sit up and want to dive into deep detail before getting on board. The question comes in the form of the old development methodology: "Let me see the high level plan and what the change will be in the deliverables and methodology over the next two years." This is exactly what you're trying to avoid by going to an Agile method.
  • try Agile on a few small projects, measure the results, talk to users about their satisfaction, and then readdress
  • nitiate the shift in the most change-prone areas first, and then work it backwards through the rest of the organization
  • It doesn't happen everywhere at all times, and it doesn't work in all areas. It's good to recognize that up front – that software development projects adapt to this easily, but an infrastructure project would have challenges with this approach. So, select a few areas that would naturally lend themselves to Agile, such as application development, gradually introduce it to these areas that need it most, and then measure results.
  • Again I'd say: "Try it." Agile transition is absolutely about organizational change. To win executive support we need to speak in terms of risk management, measurement and the bottom line.
Yuval Yeret

James Shore: The Art of Agile Development: Simple Design - 0 views

www.jamesshore.com/...simple_design.html

james shore art development

shared by Yuval Yeret on 13 Jan 15 - No Cached
  • Simple Design AudienceProgrammers Our design is easy to modify and maintain
  • Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. —Antoine de Saint-Exupéry Any intelligent fool can make things bigger, more complex and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction. —Albert Einstein
  • When writing code, agile developers often stop to ask themselves, "What is the simplest thing that could possibly work?" They seem to be obssessed with simplicity. Rather than anticipating changes and providing extensibility hooks and plug-in points, they create a simple design that anticipates as little as possible, as cleanly as possible. Unintuitively, this results in designs that are ready for any change, anticipated or not.
  • ...10 more annotations...
  • I don't think XP and patterns are conflicting. It's how you use patterns. The XP guys have patterns in their toolbox, it's just that they refactor to the patterns once they need the flexibility
  • You Aren't Gonna Need It (YAGNI) This pithy XP saying sums up an important aspect of simple design: avoid speculative coding. Whenever you're tempted to add something to your design, ask yourself if it supports the stories and features you're currently delivering. If not, well... you aren't gonna need it. Your design could change. Your customers' minds could change.
  • We do this because excess code makes change difficult. Speculative design, added to make specific changes easy, often turns out to be wrong in some way, which actually makes changes more difficult. It's usually easier to add to a design than to fix a design that's wrong. The incorrect design has code that depends on it, sometimes locking bad decisions in place.
  • Once and Only Once
  • avoid duplication. "Once and only once" is the Extreme Programming phrase. The authors of The Pragmatic Programmer [Hunt & Thomas] use "don't repeat yourself," or the DRY principle.
  • Self-Documenting Code Simplicity is in the eye of the beholder. It doesn't matter much if you think the design is simple; if the rest of your team or future maintainers of your software find it too complicated, then it is.
  • What if we know we're going to need a feature? Shouldn't we put in a design hook for it? In XP, the plan can change every week. Unless you're implementing the feature that very week, don't put the hook in. The plan could change, leaving you stuck with unneeded code.
  • Results When you create simple designs, you avoid adding support for any features other than the ones you're working on in the current iteration. You finish work more quickly as a result. When you use simple design well, your design supports arbitrary changes easily. Although new features might require a lot of new code, changes to existing code are localized and straightforward.
  • Simple design requires continuous improvement through refactoring and incremental design and architecture. Without it, your design will fail to evolve with your requirements. Don't use simple design as an excuse for poor design. Simplicity requires careful thought. As the Einstein quote at the beginning of this section says, it's a lot easier to create complex designs than simple ones. Don't pretend "simple" means "fastest" or "easiest.
  • Until recently, the accepted best practice in design followed the advice Erich Gamma now disavows: "The key to maximizing reuse lies in anticipating new requirements and changes to existing requirements, and in designing your systems so they can evolve accordingly."
Yuval Yeret

TestPyramid - 0 views

martinfowler.com/...TestPyramid.html

twitterfavs test pyramid testing agile resting agile testing mikecohn article agile-testing-list

shared by Yuval Yeret on 21 Mar 14 - No Cached
  • Yuval Yeret on 21 Mar 14
     
    bliki: A brief explanation of the Test Pyramid http://t.co/DCItjobY
Yuval Yeret

Permanent Link to Feature Flow - Increasing velocity using Kanban - 1 views

blog.xebia.com/...feature-flow-1

lean kanban

shared by Yuval Yeret on 03 Jun 09 - Cached
  • team that had some problems getting their process right
  • their velocity was decreasing and spirits were low. Luckily we managed to change our process by changing some basic Scrum practices and replacing some of them with Lean practices, inspired by the new Kanban articles and presentations. Productivity is now higher than ever and we can now focus on what really matters: product quality and customer satisfaction.
  • one major issue: getting things done. The major symptom was the frustration of management and the team with the project. The first 3-week time box (sprint) ending with about 30% (!) of all features still in progress, when, of course, they should all have been done and ready for shipment.
  • ...9 more annotations...
  • existing solution to this problem was to lower the expected velocity each sprint, so the next sprint would be on-time. But at the end of next sprint, the same problem occurred, so the velocity was going down sprint after sprint.
  • pressure of the rest of the organisation for the team to keep up their tempo. This pressure from both sides was crushing morale.
  • The way this team reacted to pressure was to work harder. Most people would have 2 or 3 tasks in progress at the same time. When a developer would finish a task, the testers were too busy testing something else, so they could give the developer direct feedback. When the tester found an issue with a new feature, the developers were already working on something else, so the tester had to wait. Simply put, there was too much focus on working long and hard, not on cooperation and the stuff that actually matters: features.
  • most dysfunctional behaviour comes from the system people are in
  • biggest struggle of this team: pressure & predictability.
  • Most Scrum masters challenge the team to reach the same (or higher) velocity each sprint. This pressure should give a team focus to perform at its best. However, it can also go haywire if the team doesn't deliver. No focus, no pride, no happy customer
  • retrospectives were dismal and planning meetings were a huge burden. The teams' productivity dropped in the days after the sprint, finding new courage to start the next one. Because they had an ineffective work-process, the only outcome of each sprint was to lower the expected velocity, to make sure we would be predictable. Estimation and predictability are only a means to an end and since they were getting in the way of fixing the root cause (and were bringing down the team's spirit) I opted to cut out the planning sessions and sprint deadlines.
  • first change we made was to set a limit of 8 tasks on the 'in progress' column
  • We spent 3 weeks bringing the numbers of open tasks from 21 to 8, without picking up any new work. Of course the team struggled with this new limit. They were used to pick up new work whenever they were blocked somehow, this wasn't allowed any more
1 - 5 of 5
Showing 20▼ items per page